Topic 13.6
Quorum
In one line
W + R > N: read the majority so at least one overlapping node has the latest write.
Think of it like this
A group decision needing 'majority vote' instead of unanimous agreement. If 3 out of 5 friends agree on a restaurant, that's enough to proceed, even if the other 2 haven't replied yet or are offline.
Key ideas
- 01
N = replica count; W = nodes that must ack a write; R = nodes read before answering.
- 02
The invariant: W + R > N guarantees a read set intersects the write set → the freshest value is seen by at least one reader node.
- 03
Dynamo-style quorum: write to W, read from R — trade durability (higher W) vs availability (lower W).
- 04
Popular configs: (N=3, W=2, R=2) — 'quorum', balanced; W=1 = fast but weak; R=1 = fast reads, stale risk.
- 05
Quorum ≠ strong consistency: without ordering/fencing, slow nodes can serve stale data (sloppy + straggler problems).
- 06
Read repair + hinted handoff keep convergence under the quorum umbrella.
- 07
Interview math to know cold: N=3 W=2 R=2 survives 1 node down; N=5 W=3 R=3 survives 2.
Code & diagrams
Why W + R > N guarantees a read always sees the latest write, even without asking every node.
Explain without notes
Prove with W+R>N why (N=3, W=2, R=2) still shows a stale read when one node is slow.
Practice
Design W/R for: user settings (durable), presence (fast), and block-buster inventory (safe).
Trade-offs
- ↔
Higher W = durable/slower writes; higher R = fresher/slower reads; the survivors count is the 2-line payoff.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can run quorum math in my head and pick W/R by failure tolerance.