Quorum Reads and Writes
A quorum is the minimum number of nodes that must participate in a read or write operation to guarantee consistency. In a system with N replicas, you configure:
- W: the number of nodes that must acknowledge a write
- R: the number of nodes that must respond to a read
The key invariant is R + W > N. This ensures that the set of nodes written to and the set of nodes read from always overlap by at least one node. That overlapping node has the latest value, so the read is guaranteed to see it.
Tunable Consistency
By adjusting W and R, you can trade off between read and write performance:
| Configuration | Write Speed | Read Speed | Use Case |
|---|---|---|---|
| W=1, R=N | Fast writes | Slow reads | Write-heavy workloads |
| W=N, R=1 | Slow writes | Fast reads | Read-heavy workloads |
| W=2, R=2 (N=3) | Balanced | Balanced | General purpose |
| W=N, R=N | Slowest | Slowest | Maximum safety |
Typical Configuration
With N=3 (common in Cassandra), W=2, R=2 is the default quorum. Any single-node failure is tolerated for both reads and writes (2 out of 3 nodes still reachable). This is the most common production setup.
Quorum Does Not Guarantee Linearizability
Even with R + W > N, quorum reads are not linearizable without additional coordination. Consider: a write is sent to nodes A and B (W=2). Before node C is updated, a read hits nodes B and C (R=2). Node B has the new value, node C has the old value. The client sees the new value. But another concurrent read might hit A and C—one old, one new. Depending on timing, different clients may disagree on the current value during the propagation window. True linearizability requires a consensus protocol (like Raft or Paxos) on top of quorum.
Sloppy Quorum
In a strict quorum, the W writes and R reads must target the designated N nodes for that key. A sloppy quorum relaxes this: if some designated nodes are down, substitute available nodes. This improves availability but weakens the consistency guarantee because the R nodes may not overlap with the W nodes (the substitutes are different machines). Hinted handoff repairs this eventually.
Real-Life: Cassandra Consistency Levels
Apache Cassandra makes quorum tunable per query with consistency levels:
- ONE: Write/read to just 1 replica. Fastest, lowest consistency. Good for time-series data where occasional stale reads are acceptable.
- QUORUM: Write/read to floor(RF/2)+1 replicas. With RF=3, that's 2. This is the default for most production workloads.
- LOCAL_QUORUM: Quorum within the local datacenter only. For multi-DC setups, avoids cross-DC latency while maintaining consistency within a region.
- ALL: Write/read to all replicas. Strongest consistency, but any single node failure causes the operation to fail.
- EACH_QUORUM: Quorum in each datacenter. Useful for global consistency across datacenters.
Example write flow with QUORUM (RF=3):
- Client sends write to a coordinator node.
- Coordinator forwards write to all 3 replicas.
- Coordinator waits for 2 ACKs (quorum = 2).
- Coordinator responds to client with success.
- The third replica eventually receives the write (or is repaired later via anti-entropy).
DynamoDB offers two consistency levels: eventual consistency (default, reads from any replica) and strong consistency (reads from the partition leader). There is no per-query tunable quorum.