Cassandra Consistency Levels
A consistency level tells Cassandra how many replica nodes must acknowledge a read or write before the operation is considered successful. Choosing the right consistency level is a trade-off between data accuracy and system availability. Cassandra gives you full control over this trade-off on a per-query basis.
The Voting Committee Analogy
Imagine a committee of five members that must approve every decision. You can require all five to agree (maximum certainty, but one absent member blocks everything), or you can require only a simple majority of three (faster decisions, still reliable). Cassandra's consistency levels work exactly like quorum rules for a committee — you choose how many "votes" from replica nodes you need before proceeding.
RF = 3 cluster (3 replicas per partition): Consistency ONE → 1 replica must respond (fastest, least consistent) Consistency TWO → 2 replicas must respond Consistency THREE → 3 replicas must respond Consistency QUORUM→ 2 replicas must respond (floor(RF/2)+1) Consistency ALL → 3 replicas must respond (slowest, most consistent)
Write Consistency Levels
ANY
The write succeeds as soon as at least one node — including the coordinator storing a hint — acknowledges it. This is the lowest durability level. Use it only when you can tolerate potential data loss and need maximum write throughput.
ONE / TWO / THREE
The write succeeds when the specified number of replica nodes confirm the write. ONE is the most commonly used write consistency level for high-throughput applications that can tolerate eventual consistency.
cqlsh> CONSISTENCY ONE; cqlsh> INSERT INTO events (event_id, name) VALUES (uuid(), 'page_view');
QUORUM
QUORUM requires a majority of replicas to respond. With RF=3, two replicas must confirm. This provides a strong balance between consistency and availability — you can lose one replica without impacting operations.
cqlsh> CONSISTENCY QUORUM; cqlsh> INSERT INTO orders (order_id, total) VALUES (uuid(), 299.99);
LOCAL_QUORUM
Like QUORUM, but only counts replicas within the local data center. Cross-data-center network latency does not affect the write's completion time. This is the recommended consistency level for most multi-datacenter production workloads.
EACH_QUORUM
A quorum of replicas must respond in every data center. Use when you need strong consistency guarantees in all regions simultaneously.
ALL
Every replica must confirm the write. One node failure causes write failures. Rarely used in production.
Read Consistency Levels
ONE / TWO / THREE
Returns data from the specified number of replicas. With ONE, Cassandra reads from the single nearest replica. If that replica holds stale data, you read stale data. Read repair runs in the background to resync the replicas.
QUORUM
Reads from a majority of replicas and returns the result with the highest timestamp. This eliminates stale reads in most scenarios.
LOCAL_ONE
Reads from the single nearest replica in the local data center. Faster than ONE in multi-datacenter setups because it avoids cross-region round trips.
LOCAL_QUORUM
Reads from a quorum of replicas in the local data center only. The recommended default for multi-datacenter deployments that need strong local consistency.
Strong Consistency with QUORUM + QUORUM
When you write at QUORUM and read at QUORUM with RF=3, at least one replica always contains the latest write. The read result is always current because the overlap between the write set (2 nodes) and read set (2 nodes) guarantees at least one shared node.
RF = 3 nodes: A, B, C
Write QUORUM → A and B confirm (B has latest data)
Read QUORUM → B and C respond (B has latest, wins by timestamp)
Result: reader always sees latest write ✓
Overlap guarantees consistency:
Write set {A,B} ∩ Read set {B,C} = {B} → at least 1 fresh copy
Tunable Consistency Table
Consistency Level Nodes Required Availability Consistency ────────────────────────────────────────────────────────────────────── ANY 1 (hint ok) Highest Lowest ONE 1 Very High Low TWO 2 High Medium THREE 3 Medium High QUORUM majority Good Strong LOCAL_QUORUM local majority Good Strong (local) EACH_QUORUM quorum per DC Lower Strongest ALL all Lowest Absolute (with RF = 3)
Setting Consistency in cqlsh
-- View current consistency level: cqlsh> CONSISTENCY; Current consistency level is ONE. -- Change it: cqlsh> CONSISTENCY QUORUM; Consistency level set to QUORUM.
Setting Consistency in Application Code (Java Driver)
SimpleStatement stmt = SimpleStatement.builder(
"SELECT * FROM orders WHERE customer_id = ?")
.setConsistencyLevel(ConsistencyLevel.LOCAL_QUORUM)
.build();
session.execute(stmt);
Serial Consistency (for Lightweight Transactions)
Lightweight transactions (IF EXISTS / IF NOT EXISTS) use a separate consistency level called serial consistency. The default is SERIAL, which contacts replicas across all data centers. LOCAL_SERIAL restricts the transaction to the local data center for lower latency.
INSERT INTO customers (customer_id, email) VALUES (uuid(), 'alice@example.com') IF NOT EXISTS USING SERIAL CONSISTENCY LOCAL_SERIAL;
Recommended Settings by Use Case
Use Case Write CL Read CL ────────────────────────────────────────────────────────────────── IoT / high-volume logging ONE ONE User-facing reads (single DC) LOCAL_QUORUM LOCAL_QUORUM User-facing reads (multi DC) LOCAL_QUORUM LOCAL_QUORUM Financial transactions QUORUM QUORUM Critical config data ALL ALL
Summary
Consistency levels let you tune the trade-off between speed and data accuracy on every query. ONE maximizes speed and availability. QUORUM provides strong consistency while tolerating one replica failure. LOCAL_QUORUM is the recommended default for multi-datacenter production clusters. Use ALL only when absolute consistency is more important than availability. Pair write and read consistency levels so their node sets always overlap to guarantee that reads reflect the latest writes.