In a Dynamo-style replicated store with N=3 replicas per key, a team sets read quorum R=1 and write quorum W=1 for maximum speed. A customer writes a new shipping address, then immediately reads it back and sometimes sees the old one. Why does this happen, and what quorum values would fix it?

## How the dial works A quorum system replicates each piece of data to N nodes and then lets you choose, independently, how many of those N nodes must participate in a write (`W`) and how many must participate in a read (`R`) before either operation is allowed to return success to the client. - A write with **W=2** out of **N=3** is acknowledged as soon as any two replicas have durably stored it — the client doesn't wait for the third. - A read with **R=2** out of N=3 queries at least two replicas and, if they disagree, resolves the disagreement (usually by comparing version numbers or timestamps and returning the newest). - The **coordinator** that receives the client's request is typically the one fanning requests out to replicas and collecting the R or W acknowledgments before replying. ## Why the dial exists The reason this exists is that it turns "consistent vs. available vs. fast" from an all-or-nothing architectural decision into a per-key, per-operation dial. Instead of picking strong consistency (wait for every replica, every time) or eventual consistency (wait for none) as a fixed global policy, quorums let a team tune R and W to land anywhere on that spectrum, and even change it operation by operation: a write-heavy, read-rarely key might use W=1, R=3; a read-heavy key might flip that around. ## The overlap arithmetic The core guarantee is arithmetic: if R + W > N, the set of replicas touched by any read is mathematically guaranteed to overlap with the set touched by any write, because you can't pick two disjoint subsets of size R and W from N items when their sizes sum to more than N. That overlap means every read includes at least one replica that has seen the most recent successful write, so the client is guaranteed to see fresh-or-newer data — commonly called a **quorum consistency guarantee**, close to but not identical to linearizability, since it hinges on choosing the freshest value among the overlapping replicas. Overlap alone isn't sufficient, though — the read still has to be able to tell which of the R responses is newest, which requires per-write **versioning** (a logical or physical timestamp, or a vector clock) carried alongside the value. Without that, "we got two different answers from two replicas" is undecidable. ## When R + W ≤ N If R + W ≤ N, there's no overlap guarantee, and you get availability and latency in exchange for possibly reading stale data — a legitimate choice for workloads that tolerate it, but a trap when a team picks low R and W purely for speed without realizing what they gave up. This is exactly the failure mode in the prompt: 1. **N=3, R=1, W=1** means a write only has to land on one replica to succeed, and a read only has to query one replica to succeed, but nothing forces it to be the same replica. 2. So a client can write to replica A, then have its very next read routed to replica B, which hasn't received the update yet via inter-replica replication. 3. **Widening to R=2, W=2** (2+2=4>3) fixes it by forcing every read to touch at least one replica from the write's target set. ## The second failure mode: drift In production, quorum-based stores show a second failure mode beyond low R+W: partial failures during the write path. If W=2 is required and a coordinator gets acknowledgment from only 1 replica before a timeout, the write itself must fail back to the client (or be retried), but by then one replica may already hold a value the other two don't — a "dangling write." Anti-entropy processes exist specifically to heal this drift: - **read repair**, where the coordinator notices divergent versions during a later read and pushes the newest value to the lagging replicas; - **hinted handoff**, where a coordinator temporarily holds a write meant for a down replica and delivers it once that replica recovers. Teams that don't run these background repair jobs, or run them too infrequently, see stale reads accumulate even with a "safe" R+W>N configuration, because overlap only guarantees freshness at the moment of the read against the replicas actually queried — it doesn't retroactively fix replicas that silently fell behind and haven't yet been touched by either a write or a repair. ## Tuning it in real stores Cassandra and Riak both expose exactly this N/R/W tuning per keyspace or per request — a common production pattern is **W=QUORUM** (majority of N) for writes and **R=ONE** for reads on a metrics or logging table where occasional staleness is cheap, versus W=QUORUM and R=QUORUM on a table backing account balances or inventory counts, where the R+W>N overlap is the whole correctness argument. The interview-relevant judgment is recognizing that R and W aren't just performance knobs — they're the mechanism that decides whether "read your own write" holds at all, and the cost of getting the overlap guarantee is strictly more replicas contacted (and more latency, bounded by the slowest of the R or W replicas) on both the read and write path.