TRICKYwalkthrough
Quorum Reads and Writes (R + W > N)
Every key lives on N = 3 replicas. A write cannot wait for all three (one slow node would drag every write), and a read cannot trust just one (it might be stale).
Write to W replicas, read from R, and if , every read set intersects every successful write set in at least one replica that has the newest value. Our defaults: W = 2, R = 2, N = 3: .
“The quorum insight: make the write set and read set overlap.”
One replica can be down or slow and both reads and writes still succeed, and reads still see the latest acknowledged write. The knobs tune per use case.
A session-token store might run R = 1, W = 1 for speed and shrug at staleness. A configuration store might run W = 3, R = 1: expensive writes, cheap always-consistent reads.
The subtle part interviewers probe: quorum overlap guarantees the read set CONTAINS the newest value, not that the coordinator can tell which one it is. The two replicas in a read set can return different values, either because a write is still propagating or because a partition let both sides accept writes.
That is why every value carries a version (a vector clock or a timestamp), the coordinator reconciles before responding, and stale replicas get fixed by read repair in the same round trip. Also worth saying out loud: quorums give read-your-writes only through the same coordinator semantics, not global linearizability: two overlapping partitions with sloppy quorums can still diverge, which is exactly the conflict-resolution problem.
What if the interviewer asks: why not W = 3 for safety? Because availability collapses: any single slow or dead replica blocks every write, and at 500 nodes something is always slow.
W = 2 is the availability/durability compromise Dynamo normalized.
Related concepts