Consistency Level

6 min reading

The Consistency Level (CL) determines how many replicas in a cluster must acknowledge a read or write operation before it is considered successful. Some of the most common Consistency Levels used are:

  • ANY - (Write Only) - The write succeeds even if all replica nodes are down, as long as the coordinator can store a hint to replay later (hinted handoff). Provides the highest write availability, but the data can’t be read until a replica receives it.
  • QUORUM - When a majority of the replicas respond, the request is honored. If RF=3, then 2 replicas respond. QUORUM is floor(n/2) + 1, where n is the Replication Factor: 2 for RF=3, 3 for RF=4 or RF=5.
  • ONE - If one replica responds; the request is honored.
  • LOCAL_ONE - At least one replica in the local data center responds.
  • LOCAL_QUORUM - A quorum of replicas in the local datacenter responds.
  • EACH_QUORUM - (unsupported for reads) - A quorum of replicas in ALL datacenters must be written to.
  • ALL - A write must be written to all replicas in the cluster, a read waits for a response from all replicas. Provides the lowest availability with the highest consistency.

Note Regardless of the Consistency Level, a write is always sent to all replicas, as set by the Replication Factor. Consistency Level controls when the coordinator reports success to the client, not how many replicas are actually updated. During a write operation, the coordinator communicates with the replicas (the number of which depends on the Replication Factor). The write is successful when the specified number of replicas confirm the write.

Write at CL=ONE with RF=3: the coordinator, Node 4, acknowledges the client after Node 1 acknowledges
Write at CL=ONE with RF=3: the coordinator, Node 4, acknowledges the client after Node 1 acknowledges

In the above diagram, the arrows on the left show the write going from the client to the coordinator and the acknowledgment coming back. Since the Consistency Level is one, the coordinator, Node 4, only waits for one replica to acknowledge the write, here Node 1. Since RF=3, the data is also written to Nodes 2 and 5, but the coordinator doesn’t wait for them before confirming a successful write. Their acknowledgments (in grey) can arrive after the coordinator has already acknowledged the client. When our Consistency Level is set to QUORUM, the coordinator must wait for a majority of nodes to acknowledge the write before it is considered successful. Since our Replication Factor is 3, the coordinator waits for 2 acknowledgments, and not for the third:

Write at CL=QUORUM with RF=3: the coordinator waits for acknowledgments from Nodes 1 and 5
Write at CL=QUORUM with RF=3: the coordinator waits for acknowledgments from Nodes 1 and 5

During a read operation, the coordinator communicates with just enough replicas to guarantee that the required Consistency Level is met. Data is then returned to the client.

Read at CL=ONE with RF=3: the coordinator reads from one replica, Node 1, and returns its value
Read at CL=ONE with RF=3: the coordinator reads from one replica, Node 1, and returns its value

Note The default CL value when using the CQL Shell is ONE. The Consistency Level is tunable per operation in CQL. This is known as tunable consistency. You set it per session (for example, with the CONSISTENCY command in cqlsh, or in the driver’s configuration) or per query. Sometimes response latency is more important, so you can lower the Consistency Level for a specific query. In other words, the Consistency Level setting allows you to choose a point in the consistency vs. latency tradeoff.

Knowledge Check

3 questions Pass 66%

Pass 66% to continue. No time limit; retake as many times as you need.

1. To achieve the highest consistency we would set:
2. With RF=3 and CL=ONE, a client writes a row. When does the coordinator report success to the client?
3. With RF=3, how many replicas must acknowledge a write at CL=QUORUM?
Back to course

Something wrong with this lesson? Tell us