Quorum Reads and Writes: R + W > N, Sloppy Quorums and Hinted Handoff
Quorum replication explained: N, R and W, why R + W > N gives overlapping reads, sloppy quorums, hinted handoff, read repair and tunable consistency.
In quorum replication, each value is stored on N replicas, a write must be acknowledged by W of them, and a read queries R of them. If R + W > N, every read set overlaps every write set in at least one replica, so a read can always find the latest acknowledged write. Tuning N, R and W lets a system trade consistency, latency and availability, which is why leaderless stores such as Dynamo-style databases expose them as settings.
Why R + W > N works
With N = 3, W = 2 and R = 2, a write reaches at least two of the three replicas, and a read asks two. Any two-replica set and any other two-replica set out of three must share a member, so at least one replica in the read has the latest value. Versions (timestamps or vector clocks) tell the reader which response is newest.
Choosing N, R and W
| Setting (N = 3) | Effect | Fits |
|---|---|---|
| W = 2, R = 2 | Overlapping quorums; tolerates one replica down for both reads and writes | A common balanced default |
| W = 3, R = 1 | Fast reads, slow writes; any one replica down blocks writes | Read-heavy data that rarely changes |
| W = 1, R = 3 | Fast writes, slow reads; reads fail if any replica is down | Write-heavy data, rarely read |
| W = 1, R = 1 | Fastest and most available, but R + W ≤ N: reads may miss recent writes | Caches, metrics, data where staleness is acceptable |
Latency follows the slowest replica in the quorum, so the client waits for the W-th or R-th fastest response. Sending requests to all N replicas and using the first W or R replies hides a slow node.
Quorums don't make everything linearizable
R + W > N is necessary but not sufficient for strong consistency. Edge cases include:
- Concurrent writes to the same key with last-write-wins by timestamp can lose a write if clocks are skewed.
- Failed writes that reached fewer than W replicas aren't rolled back on the replicas they did reach, so later reads may see them.
- A read concurrent with a write may return the new value from one replica and then the old value on a subsequent read from different replicas.
- Sloppy quorums (below) break the overlap guarantee.
Systems that need linearizable reads and writes use a single leader with consensus, or add read repair and coordination on top. See consistency models.
Sloppy quorums and hinted handoff
If some of a key's N home replicas are unreachable, a strict quorum fails the write. A sloppy quorum accepts the write on other healthy nodes instead, which store it with a hint naming the intended replica. When the home replica recovers, hinted handoff sends it the data. This raises write availability during failures, at the cost that a read quorum may not overlap the nodes holding the newest value until handoff completes.
Keeping replicas converged
- Read repair: when a read sees replicas with different versions, it writes the newest value back to the stale ones.
- Anti-entropy: a background process compares replicas and copies missing data, using Merkle trees to find differences cheaply.
- Conflict resolution: concurrent versions are reconciled with last-write-wins, version vectors with application merges, or CRDTs.
Where it’s used
Cassandra and similar databases let each query choose its consistency level, such as ONE, QUORUM or ALL.
Raft and Paxos use majority quorums (a special case where W and R are majorities) for leader election and commits.
Local-region quorums keep latency low, with cross-region replication done asynchronously.
In an interview
- Explain why R + W > N gives overlap, with a concrete N = 3 example.
- Show how changing R and W shifts latency and availability.
- Point out that quorums alone don't guarantee linearizability.
- Describe sloppy quorums, hinted handoff, read repair and anti-entropy.
Further reading
- Dynamo: Amazon's Highly Available Key-value StoreAll Things Distributed (Werner Vogels)
- Apache Cassandra: Tunable consistencyApache Cassandra documentation