Distributed Systems for Backend Engineers · Data Distribution and Agreement
Quorums and Tunable Consistency
R + W > N and what it does (and doesn't) guarantee.
In leaderless systems with N replicas, a write waits for W acknowledgments and a read queries R replicas. If R + W > N, read and write sets overlap, so a read sees at least one up-to-date replica (with version comparison). Cassandra exposes this as consistency levels (ONE, QUORUM, LOCAL_QUORUM, ALL). Quorums don't give linearizability by themselves (concurrent writes, sloppy quorums, failed writes) — they're a tunable trade-off between latency, availability and staleness.
Quorum configurations
| Setting (N=3) | Read latency | Write latency | Staleness risk |
|---|---|---|---|
| W=1, R=1 | Lowest | Lowest | High |
| W=2, R=2 (quorum) | Medium | Medium | Low |
| W=3, R=1 | Lowest reads | Highest writes; any node down blocks writes | Low |
| W=1, R=3 | Highest reads | Lowest writes | Low |
-- Cassandra: strong-ish reads in one datacenter
CONSISTENCY LOCAL_QUORUM;
INSERT INTO carts (user_id, item_id, qty) VALUES (42, 'sku-1', 2);
SELECT * FROM carts WHERE user_id = 42;
Common pitfalls
- Assuming QUORUM means linearizable.
- Cross-region QUORUM latency surprises (use LOCAL_QUORUM).
- Ignoring hinted handoff/sloppy quorum behavior during failures.
Key points
- R + W > N ⇒ overlap
- Tunable latency vs staleness
- Not automatically linearizable
Further reading: Cassandra: Dynamo architecture
Practice questions
Why does R + W > N help reads see the latest write?
Answer
Every read set overlaps every write set in at least one replica, which has the latest acknowledged value (resolved by version).
Why use LOCAL_QUORUM in multi-region Cassandra?
Answer
It achieves quorum within the local datacenter, avoiding cross-region round trips while keeping strong local consistency.
Open in the app to mark lessons complete, take notes and track your progress.