= Guarantees

Apache Cassandra is a highly scalable and reliable database. Cassandra
is used in web based applications that serve large number of clients and
the quantity of data processed is web-scale (Petabyte) large. Cassandra
makes some guarantees about its scalability, availability and
reliability. To fully understand the inherent limitations of a storage
system in an environment in which a certain level of network partition
failure is to be expected and taken into account when designing the
system it is important to first briefly introduce the CAP theorem.

== What is CAP?

According to the CAP theorem it is not possible for a distributed data
store to provide more than two of the following guarantees
simultaneously.

* Consistency: Consistency implies that every read receives the most
recent write or errors out
* Availability: Availability implies that every request receives a
response. It is not guaranteed that the response contains the most
recent write or data.
* Partition tolerance: Partition tolerance refers to the tolerance of a
storage system to failure of a network partition. Even if some of the
messages are dropped or delayed the system continues to operate.

CAP theorem implies that when using a network partition, with the
inherent risk of partition failure, one has to choose between
consistency and availability and both cannot be guaranteed at the same
time. CAP theorem is illustrated in Figure 1.

image::Figure_1_guarantees.jpg[image]

Figure 1. CAP Theorem

High availability is a priority in web based applications and to this
objective Cassandra chooses Availability and Partition Tolerance from
the CAP guarantees, compromising on data Consistency to some extent.

Cassandra makes the following guarantees.

* High Scalability
* High Availability
* Durability
* Eventual Consistency of writes to a single table
* Lightweight transactions with linearizable consistency
* Batched writes across multiple tables are guaranteed to succeed
completely or not at all
* Secondary indexes are guaranteed to be consistent with their local
replicas data

== High Scalability

Cassandra is a highly scalable storage system in which nodes may be
added/removed as needed. Using gossip-based protocol a unified and
consistent membership list is kept at each node.

== High Availability

Cassandra guarantees high availability of data by implementing a
fault-tolerant storage system. Failure detection in a node is detected
using a gossip-based protocol.

== Durability

Cassandra guarantees data durability by using replicas. Replicas are
multiple copies of a data stored on different nodes in a cluster. In a
multi-datacenter environment the replicas may be stored on different
datacenters. If one replica is lost due to unrecoverable node/datacenter
failure the data is not completely lost as replicas are still available.

== Eventual Consistency

Meeting the requirements of performance, reliability, scalability and
high availability in production Cassandra is an eventually consistent
storage system. Eventually consistent implies that all updates reach all
replicas eventually. Divergent versions of the same data may exist
temporarily but they are eventually reconciled to a consistent state.
Eventual consistency is a tradeoff to achieve high availability and it
involves some read and write latencies.

== Lightweight transactions with linearizable consistency

Data must be read and written in a sequential order. Paxos consensus
protocol is used to implement lightweight transactions. Paxos protocol
implements lightweight transactions that are able to handle concurrent
operations using linearizable consistency. Linearizable consistency is
sequential consistency with real-time constraints and it ensures
transaction isolation with compare and set (CAS) transaction. With CAS
replica data is compared and data that is found to be out of date is set
to the most consistent value. Reads with linearizable consistency allow
reading the current state of the data, which may possibly be
uncommitted, without making a new addition or update.

== Batched Writes

The guarantee for batched writes across multiple tables is that they
will eventually succeed, or none will. Batch data is first written to
batchlog system data, and when the batch data has been successfully
stored in the cluster the batchlog data is removed. The batch is
replicated to another node to ensure the full batch completes in the
event the coordinator node fails.

== Secondary Indexes

A secondary index is an index on a column and is used to query a table
that is normally not queryable. Secondary indexes when built are
guaranteed to be consistent with their local replicas.