Quorum Reads & Writes (R + W > N).

❌The myth

"I set N=3, W=2, R=2. Since R + W > N, my reads are strongly consistent."

Almost every distributed-DB tuning guide implies this. It's the single most confidently-wrong thing intermediate engineers believe about replication.

✅Actually

R + W > N buys you exactly ONE thing: overlap.

With N=3, W=2, R=2 — pigeonhole: a write touched 2 of 3 nodes, a read touches 2 of 3, so at least 1 node in your read set has the latest acknowledged write.

That's it. Overlap means the newest value is present in the responses. It does NOT mean you return it, and it says nothing about ordering.

🕳️Where it actually breaks

1️⃣ Overlap ≠ picking the right version

You get 2 responses: node A says balance=100, node B says balance=120. Overlap guarantees 120 is in there. It doesn't pick it for you. If your client returns the first response, or the fastest, you serve stale data with perfect quorum math.

2️⃣ Last-write-wins is a data-loss switch

Most systems resolve by wall-clock timestamp. Two clients write at 12:00:00.000 on nodes whose clocks drift 30ms apart → one write silently disappears. No error, no conflict, no log line. Quorum never promised you ordering — only overlap.

3️⃣ "Failed" writes are not rolled back

Write with W=2 gets 1 ack, then times out. Client sees an error and retries elsewhere. But that 1 replica keeps the value, and read-repair can spread it later. A write your app believes failed can become the winning value tomorrow.

4️⃣ Sloppy quorums break the math entirely

Cassandra/Dynamo-style hinted handoff: if the "right" nodes are down, W acks come from substitute nodes outside the preference list. Your read hits the real N nodes and finds nothing. R + W > N is now arithmetic about two different sets.

🎛️What the knobs really trade

W=1 R=1  → fast, no overlap, read-your-writes not guaranteed
W=3 R=1  → fast reads, but ONE node down = all writes fail
W=2 R=2  → overlap + survives 1 node loss (the usual pick)
W=2 R=1  → no overlap; fine for caches, not for money

Try it (Cassandra):

cqlsh> CONSISTENCY QUORUM;
cqlsh> UPDATE accounts SET balance=120 WHERE id=1;
cqlsh> CONSISTENCY ONE;
cqlsh> SELECT balance FROM accounts WHERE id=1;

Run that read in a loop while one node is down and rejoining. Watch it flip between 100 and 120.

🧠The correct mental model

Quorum is a DURABILITY and AVAILABILITY dial, not a consistency dial. It ensures data survives f failures and that a read can see the truth. Turning "can see" into "always returns" needs versioning (vector clocks), a conflict resolution policy you chose on purpose, and repair. If you need real linearizability, you need consensus — Raft/Paxos — not quorum arithmetic.

🏋️Your exercise

N=5, W=3, R=3. Two clients write to the same key at the same moment, each reaching a different set of 3 nodes. Both get success. Now a reader queries 3 nodes.

Which value does it return — and what's the smallest change to your schema or write path that makes the answer deterministic instead of "whichever clock was ahead"?