Store every key on three machines and you can survive one failing. But then every write has to reach three places, and every read has to decide which copy to believe. Waiting for all three makes the system as fragile as its slowest machine. Waiting for one makes reads return stale data.
Quorums sit in between. Amazon's Dynamo paper (2007) popularised the idea, and Cassandra, Riak and ScyllaDB use it today.
Three numbers
- N — how many replicas store each key (the replication factor).
- W — how many must confirm a write before it counts as successful.
- R — how many must answer a read.
If R + W > N, every set of R replicas overlaps every set of W replicas, so at least one replica in any read has the latest successful write.
Each key is stored on N = 3 replicas. A write succeeds once W replicas confirm; a read asks R replicas. Choosing R + W > N guarantees the two sets overlap.
Choosing R and W
With N = 3:
| W | R | R + W > N? | character |
|---|---|---|---|
| 2 | 2 | yes | the usual balance: tolerates one slow or failed replica on both paths |
| 3 | 1 | yes | fast reads, but any one replica down blocks writes |
| 1 | 3 | yes | fast writes, but reads need every replica |
| 1 | 1 | no | fastest; reads may be stale — eventual consistency |
Cassandra exposes this per query, as consistency levels: ONE, QUORUM
(a majority), ALL, and their datacentre-local versions (LOCAL_QUORUM).
Using QUORUM for both reads and writes gives R + W > N.
"Newest" needs versions
When replicas disagree, the coordinator must decide which value is newer:
- Timestamps with last-write-wins (Cassandra's default): simple, but clock skew between machines can make an older write win, and concurrent writes silently lose data.
- Vector clocks (the Dynamo paper, Riak): detect when two writes were concurrent and keep both "siblings" for the application to merge — like the classic shopping cart that merges two versions instead of dropping one.
Keeping replicas in sync
Quorums tolerate replicas falling behind; other mechanisms bring them back:
- Read repair: when a read sees a stale replica, it writes the newer value back to it.
- Hinted handoff: when a replica is down during a write, another node stores the write with a "hint" and delivers it when the replica returns.
- Anti-entropy: background jobs compare replicas using Merkle trees — hashes of key ranges — so only the ranges that differ are transferred.
The fine print
R + W > N is weaker than it sounds:
- Sloppy quorums: to stay writable during a partition, some systems accept writes on nodes outside the key's usual replicas. Those writes may not overlap with a later read quorum, so the guarantee lapses.
- Failed writes leave traces: a write that reached only one replica (and was reported as failed) may still be returned by later reads — or not, depending on which replicas answer.
- Concurrent reads and writes can see different results while a write is in flight.
- No transactions: quorums are per key. Updating two keys together needs something else.
So quorum systems are usually described as tunable, eventually consistent stores — not linearizable ones. For strict guarantees, use a consensus protocol like Raft, where a single leader orders all writes. See CAP and eventual consistency for where each fits.
In a design interview
When you add a replicated store, say how many replicas you keep and what
consistency each operation needs: "Writes to the shopping cart use
LOCAL_QUORUM; product view counters use ONE, because a slightly stale
count is fine." That shows you know the dial exists and that different data
deserves different settings.