Consider a key replicated on 5 nodes (N=5) with write quorum W=3 and read quorum R=2. Walk through why a read is, or is not, guaranteed to return the most recently acknowledged write. How would the answer change if R were increased to 3?

## Why the boundary case fails This scenario is a deliberately boundary case, because R+W=N (rather than R+W>N) is a common off-by-one mistake when people reason about quorums quickly, and understanding exactly why it fails clarifies the whole mechanism. Start with the write: - The coordinator sends the new value to some or all of the 5 replicas and waits until 3 of them acknowledge durable storage before telling the client the write succeeded. - Which 3 replicas actually respond first is not fixed in advance — it depends on network latency and load at that moment, so over many writes, different 3-of-5 subsets can end up holding the 'latest' write while the remaining 2 are still on an older version (they'll eventually catch up via replication, but at the moment right after the write, they may not have it yet). ## The read that can miss Now the read: the coordinator queries **2 of the 5 replicas** and returns whichever response looks newest. The critical question is whether those 2 replicas are guaranteed to include at least one of the 3 that held the latest write. With 5 total replicas split into a hypothetical 3 (wrote) and 2 (didn't write yet), the read's 2-replica query could, in the worst case, land exactly on those 2 laggards — a perfectly valid subset of size 2 out of 5, disjoint from the write's 3. In that case, both replicas the read consults are still on the old version, and the client returns stale data with full confidence, because from its point of view both replicas it asked agreed (there's no third opinion contradicting them). This isn't a rare pathological case — under normal operation, if the read coordinator happens to prefer contacting the fastest-responding or geographically nearest replicas, and those overlap poorly with which replicas happened to ack the write fastest, stale reads become a real, recurring behavior, not just a theoretical edge case. ## The counting argument The reason the arithmetic matters is the **pigeonhole principle**: two subsets of an N-element set can only be guaranteed to intersect if their sizes sum to more than N. 1. At exactly R+W=N, you can always construct a partition (write-set, read-set) that exactly tiles the N replicas with zero overlap — that's precisely what happened above (3 + 2 = 5, tiling all 5 replicas exactly). 2. Only once R+W > N does the counting argument break: if the write's 3 replicas and the read's (now) 3 replicas were disjoint, that would require 3+3=6 distinct replicas, but only 5 exist, which is impossible. 3. So at least one replica must be counted in both sets — guaranteeing the read touches at least one replica holding the latest write. ## What raising the read quorum costs Raising R from 2 to 3 has real operational cost, which is the trade-off every quorum tuning decision makes. - **Latency.** The read now has to wait for 3 replicas to respond instead of 2, so its latency is bounded by the third-fastest replica rather than the second-fastest — typically a modest but real increase, and it becomes worse under replica slowness or partial outages. - **Fault tolerance.** Since now 3 of the 5 replicas must be reachable for the read to even complete (versus 2 before), reducing the operation's fault tolerance from 3 simultaneous failures survivable down to 2. This is the general pattern: pushing the consistency guarantee (via R+W>N) costs latency and availability headroom on whichever side you increase. ## Where this shows up in production A concrete production analog: this is exactly the class of bug that shows up when a team configures a Cassandra-style store with, say, ONE-consistency writes and ONE-consistency reads against RF=3 (N=3, effectively W=1,R=1, R+W=2<3) expecting 'good enough' consistency, then is surprised by visibly stale reads right after a write under load — and the fix discussion is identical to this scenario: - raise R - raise W - accept the eventual-consistency window and add client-side techniques like read-your-writes session stickiness to the same replica that served the write