Quorum reads and writes

You have 5 copies of a value, one on each of 5 servers. A client writes a new value. It sends the update to some subset of the copies, then returns success. Another client immediately reads the value, from another subset. What guarantee can you make about what the reader sees?

This is the quorum problem, and it has a beautifully simple answer: if R + W > N, every read sees at least one copy of the latest write. Not "usually." Not "most of the time." Every read. That inequality is the foundation of every eventually-consistent database that offers "strong reads" — Dynamo, Cassandra, Riak, MongoDB (write concern + read concern), Elasticsearch. All of them.

The proof takes 10 seconds. If a write hits W of N copies, and a read hits R of N copies, then by the pigeonhole principle the write set and the read set must overlap in at least R + W − N copies. If R+W>N, that overlap is at least 1 — meaning the reader sees at least one copy that has the write. Dynamo-style stores tag every value with a timestamp; the reader picks the latest and returns it. Strong read guarantee, no coordinator, no leader.

Interactive: the R + W > N slider

Move the sliders. Watch the overlap between the read set and the write set change. When R+W>N, the sets overlap. When R+W ≤ N, they don't — and you can read stale data.

The two knobs — R and W independently

The beauty of quorum systems is that you can pick R and W per request. Both writes and reads have a latency-consistency-availability triangle. The two knobs let you slide along it independently:

• Write-heavy workload — W=1 (fast writes), R=N (slow reads that see everything). Event logging lands here.
• Read-heavy workload — W=N (slow writes, maximum durability), R=1 (fast reads). Read-mostly documents.
• Balanced OLTP — W=⌈N/2⌉+1, R=⌈N/2⌉+1 (both quorum). Symmetric latency, strong consistency. Industry default.
• Availability-only — W=1, R=1. Fast on both paths. No consistency guarantee. Analytics or metrics.

The proof visualized — pigeonhole

Here's why R+W>N is a mathematical guarantee, not a probabilistic one. N=5 replicas. A write hits W=3 of them (blue). A subsequent read hits R=3 of them (yellow). The 5 slots contain 3+3=6 "hits" total. If they didn't overlap anywhere, you'd need 6 slots — but only 5 exist. So they must overlap in at least 1 slot. That slot has the write, so the reader sees it.

Sloppy quorum — the availability trick

Strict quorum has a problem: if 3 of your 5 replicas are down, you can't achieve W=3. Requests fail. Dynamo introduced sloppy quorum to preserve availability during partial failures: if a write can't reach W of the designated replicas, it writes to nearby healthy nodes instead (called hinted handoff). When the intended replicas come back, the hint is replayed. Sloppy quorum preserves availability but weakens consistency — a subsequent read might hit only the intended replicas and miss the value entirely.

Quorum is not the same as consensus

Quorum systems and consensus systems (Raft, Paxos) both use majorities. Both tolerate f failures with N=2f+1. But the similarities end there.

Rough rule of thumb: use consensus when you need one agreed-upon value (leader, metadata state, log entry). Use quorums when you need many independently-updated values (user rows, cache entries, counter shards). Consensus doesn't scale to millions of objects; quorums don't give you a total order across objects.

Applied in real systems

Every quorum-based store below made a specific choice about R, W, N, sloppy quorum, and conflict resolution.

Key takeaways

• R + W > N guarantees every read sees the latest write — by pigeonhole, not probability.
• The overlap is R + W − N copies. Pick R=W=⌈N/2⌉+1 for symmetric latency; skew for asymmetric workloads.
• Quorum ≠ Consensus. Quorums handle many independent values (KV). Consensus handles one agreed value (leader). Different tools.
• Sloppy quorum (Dynamo, Riak, Cassandra) trades consistency for availability during partial failures.
• Quorum alone doesn't handle conflict — it needs a resolution rule: vector clocks or last-write-wins timestamps at read time.
• Every distributed database calls R=W=⌈N/2⌉+1 "QUORUM." Industry-standard OLTP default.

References

• Gifford (1979) — Weighted Voting for Replicated Data. SOSP 1979.
• DeCandia et al. (2007) — Dynamo: Amazon's Highly Available Key-value Store. SOSP 2007.
• Lakshman & Malik (2010) — Cassandra: A Decentralized Structured Storage System.
• Kleppmann (2017) — Designing Data-Intensive Applications, Ch. 5.
• Werner Vogels — "Eventually Consistent." Amazon blog, 2008.