Interview Prep Zoneby CuriouserLabs

Question 3 of 5 · staff level

Explain quorum reads and writes: why R + W > N, and where the guarantee leaks.

🎤 Say this first

In a leaderless store with N replicas, a write waits for W acknowledgements and a read collects R responses. If R + W > N, the read set and the write set must overlap in at least one replica, so any successful read sees at least one copy of the latest successful write — and version metadata lets the client pick it. Common settings: N=3, W=2, R=2 (balanced); W=N, R=1 (fast reads, fragile writes); W=1, R=1 (fastest, no overlap, purely eventual). The guarantee is weaker than it looks: it leaks on concurrent writes (overlap tells you the newest value exists, not which of two concurrent values wins), on sloppy quorums (W acks from any nodes, not the right ones), on partial write failures that leave the write on some replicas anyway, and on non-durable acks.

The full picture

🎬 Quorums: why R + W > N is the whole guarantee

1 / 5
W = 2R = 2Replica 1v1Replica 2v1Replica 3v1Writersends v2Readerwants latestSloppy quorums accept W acks from ANY node, which quietly voids this overlap.

N = 3 replicas hold the key, currently at v1. A write waits for W acknowledgements; a read collects R responses. Nobody coordinates — the client does the arithmetic.

N=3, W=2, R=2 — watch the read set and write set share a node, then watch W=1 break it.
  • The intuition in one line: R + W > N is the pigeonhole principle — you cannot pick R nodes and W nodes from N without repeating one, and that repeated node carries the newest version.
  • Latency tuning is the real reason to change R and W: read-heavy workloads use W=N/R=1 to make reads single-hop; write-heavy use W=1/R=N. And because the client waits for the slowest of W, higher quorums expose you to tail latency — this is exactly why Dynamo-style systems send requests to more replicas than they wait for.
  • Sloppy quorums + hinted handoff trade the guarantee for availability: if the home replicas are unreachable, W acks are taken from any healthy nodes, which then hand the data off later. Writes keep succeeding during a partition, but R + W > N no longer implies overlap with the home replicas, so reads can miss the write. Naming this as 'availability bought with a weakened guarantee' is the precise framing.
  • Partial failure has no rollback: a write that reaches 1 of 3 replicas but needed W=2 returns an error to the client — and the value stays on that one replica. A later read may return it. So 'my write failed' does not mean 'my write didn't happen', which is exactly why idempotency and version checks matter more than error handling here.
  • Quorums don't give you linearizability on their own — they give overlap. Real linearizable operations in these systems need consensus per key (Cassandra's lightweight transactions, DynamoDB's conditional writes). Knowing that quorum ≠ linearizable is the distinction interviewers probe for at staff level.
N / W / RReadsWritesUse when
3 / 2 / 2overlap ✅tolerates 1 node downthe sane default
3 / 3 / 1fastestfails if any node is downread-dominated, tolerant of write outages
3 / 1 / 3slowestfastest, most availablewrite-dominated ingest
3 / 1 / 1no overlap ❌fastestcaches, metrics, genuinely disposable data
5 / 3 / 3overlap ✅tolerates 2 downhigher durability, higher tail latency

🔄 Likely follow-up questions

  • With N=3, W=2, R=2, construct a case where a read still returns stale data.
  • What does hinted handoff actually store, and what happens if the hint is lost?
  • Why do Dynamo-style clients send requests to more replicas than they wait for?