Consistency Levels in Cassandra: Ensuring Reliable Data Reads and Writes
Cassandra Consistency Level Diagram – QUORUM vs LOCAL_QUORUM vs ALL
Overview
In Apache Cassandra, consistency levels define how many replicas must acknowledge a read or write request before the operation is considered successful. This flexibility allows Cassandra to balance availability, latency, and data accuracy depending on your application’s needs.
This article explores different consistency levels in Cassandra, how they work, and how to choose the right one for your use case.
Consistency in Cassandra refers to the agreement among replicas on the value of a given piece of data. When a client performs a read or write, the consistency level determines how many replicas need to respond for the operation to be successful.
Cassandra follows the CAP theorem, which states that a distributed system can provide only two of the following three:
Consistency (C) – Every read receives the most recent write.
Availability (A) – Every request receives a response (even if not the latest data).
Partition Tolerance (P) – The system continues to operate despite network failures.
Cassandra is AP by default but allows you to tune consistency levels to approach strong consistency when needed.
When a client sends a write request, Cassandra’s coordinator node forwards it to multiple replicas. The consistency level determines how many replicas must acknowledge before confirming success.
Similarly, for a read request, Cassandra can fetch data from multiple replicas to ensure accuracy based on the consistency level.
Cassandra supports different consistency levels for reads and writes, each offering a trade-off between performance and accuracy.
The write is successful if at least one node (including hints) receives the data.
Fastest, but lowest consistency.
Used for: High write availability.
Requires acknowledgment from one replica.
Low latency, moderate consistency.
Used for: Fast, non-critical applications.
Waits for acknowledgment from 2 or 3 replicas respectively.
Increases reliability and consistency.
Used for: Balanced performance and accuracy.
A majority (N/2 + 1) of replicas must respond.
Offers strong consistency with good availability.
Used for: Production systems needing reliable data.
A quorum of replicas in the local data center must respond.
Reduces latency in multi-DC setups.
Used for: Multi-data-center applications.
Requires a quorum of replicas from each data center.
Ensures cross-DC consistency but adds latency.
Used for: Critical multi-region operations.
All replicas must acknowledge.
Strongest consistency, lowest availability.
Used for: Financial or critical systems where accuracy is vital.
Requires acknowledgment from one replica in the local data center.
Optimized for low-latency local reads.
Used for: Real-time applications with geo-distribution.
CONSISTENCY QUORUM;
SELECT * FROM users WHERE user_id = 101;
You can also set consistency programmatically via your Cassandra driver (Python, Java, Node.js, etc.).
| Replication Factor (RF) | Consistency Level | Tolerated Failures | Notes |
|---|---|---|---|
| 3 | ONE | 2 | Fast but may read stale data |
| 3 | QUORUM | 1 | Balanced consistency and availability |
| 3 | ALL | 0 | Strong consistency, low availability |
To achieve strong consistency, the sum of the read and write consistency levels must be greater than the replication factor (RF):
R + W > RF
If RF = 3,
Write Consistency = QUORUM (2)
Read Consistency = QUORUM (2)
→ 2 + 2 > 3 → Strong consistency achieved.
| Type | Levels | Description |
|---|---|---|
| Global | ONE, TWO, THREE, QUORUM, ALL | Applies across all data centers. |
| Local | LOCAL_ONE, LOCAL_QUORUM, EACH_QUORUM | Restricts to local or per-DC consistency. |
Local levels reduce latency by keeping communication within the same data center.
Use QUORUM for most production workloads.
Use LOCAL_QUORUM for multi-DC clusters.
Avoid ALL unless data accuracy is more critical than availability.
Use ANY only for writes that can tolerate eventual consistency.
Monitor latency and tune consistency levels per operation type.
CONSISTENCY ONE;
INSERT INTO users (id, name) VALUES (101, 'Amit');
CONSISTENCY QUORUM;
SELECT * FROM users WHERE id = 101;
Cassandra’s tunable consistency model gives you the power to control the balance between speed, availability, and accuracy.
Use QUORUM or LOCAL_QUORUM for most production systems.
Choose ALL for critical transactions.
Prefer ONE or LOCAL_ONE for faster, less critical reads.
By tuning consistency levels based on workload and topology, you can make Cassandra both highly available and reliably consistent.