Distributed Systems
Quorums: multiple-choice review
Crux Multiple-choice synthesis across the quorum unit: R + W > N arithmetic, tunable consistency, sloppy quorum and hinted handoff, and the silent production failure modes.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each is a decision you make when you size a cluster or debug a stale-read ticket — not a definition to recite, but R, W, and N arithmetic under real failures.
Goal
Confirm you can derive the overlap guarantee from R + W > N, place a config on the consistency/availability/latency triangle, and predict exactly which guarantee sloppy quorum forfeits during a partition.
Quiz
Completed
A cluster runs RF=5. You need every read guaranteed to see the latest successful write while tolerating as many node failures as possible. What is the minimal (R, W) that still gives strong consistency, and how many simultaneous node failures does it survive on each path?
Heads-up 5 is not strictly greater than 5. R + W must be > N, not >= N. With R=2, W=3 a read can pick 2 replicas that both missed the write and return stale data.
Heads-up Sum 6 > 5 does guarantee overlap, but W=5 means a single node down fails every write — it tolerates 0 write failures, the opposite of 'as many failures as possible.' QUORUM R=3,W=3 tolerates 2 on each path.
Heads-up Sum 6 > 5 gives overlap, but R=5 means one slow or down node blocks every read, tolerating 0 read failures, and W=1 risks losing the ack if the lone node dies. QUORUM balances both paths.
Quiz
Completed
A payments service at RF=3 runs writes at W=1 'for latency.' One night a node acks a payout-account update, then crashes during a deploy before replicating. The next read serves the old account number. What actually went wrong?
Heads-up Replication behaved exactly as configured. W=1 means 'ack after one replica' — the runtime never promised the other two would receive it before acking. The loss is a configuration choice, not a code defect.
Heads-up R=3 with W=1 sums to 4 > 3 and would have caught a surviving copy — but here the only copy died, so even R=3 finds nothing. The root cause is W=1 durability, not the read setting.
Heads-up A deploy is just one trigger. Any crash, GC pause, or disk failure in the window after a W=1 ack and before replication loses the write. W=1 makes single-replica failure a data-loss event.
Quiz
Completed
Same RF=3 cluster, configured strict W=2, R=2. During a network partition a write lands via sloppy quorum on hint-holding substitute nodes, and a strict read on the home replicas returns stale data. Why does W=2, R=2 not save you here?
Heads-up It keeps your W count — two nodes still ack. What changes is WHICH nodes can satisfy it: healthy substitutes via hinted handoff, not the designated replicas. The counts are unchanged; the membership is.
Heads-up Read repair can only push a newer version it can see. During the partition the latest write is on hint-holders the read never contacts, so there is no fresher copy at the read for repair to propagate.
Heads-up R=3 reads all three home replicas, but the hinted write is on substitute nodes outside that set, so R=3 still misses it mid-partition. The hole is the suspended overlap, not the R value.
Quiz
Completed
A team argues 'R=1, W=2 is fine at N=3 because the write is already on a majority.' What is wrong with the reasoning?
Heads-up A majority write guarantees the value is on 2 of 3, but R=1 can pick the remaining 1 that missed it. Consistency comes from forced intersection (R + W > N), not from the write being on a majority.
Heads-up W=2 is exactly QUORUM and is fine — paired with R=2. The flaw is R=1, which drops the sum to 3 and breaks overlap. Fix the read, not the write.
Heads-up There is no guarantee the coordinator holds the key or the latest version; coordinators route, they are not necessarily replicas. Overlap must come from the R + W > N math, not from routing luck.
Quiz
Completed
At RF=3 a QUORUM read (R=2) shows p99 latency far worse than its p50, while the cluster's per-node latencies look healthy. What is the mechanism, and what mitigation targets it directly?
Heads-up The latency is dominated by waiting on the slowest required replica, not coordinator CPU. More cores do nothing for a read blocked on a GC-paused replica; hedging or lowering R does.
Heads-up Read repair fires only when replicas disagree and is usually cheap. The structural p99 driver is 'wait for the 2nd-fastest of 3' — a tail-latency property of R itself.
Heads-up R=1 does cut the wait, but at N=3 with W=2 it drops R + W to 3 and breaks the overlap guarantee. Hedging clips the tail WITHOUT sacrificing consistency; dropping R trades correctness for latency.
Quiz
Completed
Overlap (R + W > N) guarantees a quorum read sees the latest committed write. Which of these does it NOT guarantee?
Heads-up This is precisely what overlap DOES guarantee: the read set and write set share a node carrying the latest value. The thing quorum does not give you is ordering of concurrent writes.
Heads-up QUORUM does provide single-node-failure tolerance on both paths — that is why it beats ALL. The missing guarantee is serialisation of concurrent writes to the same key.
Heads-up Tunable consistency genuinely lets you set R and W per query. The guarantee overlap does NOT provide is ordering concurrent writes — visibility is not serialisation.
Recap
The through-line is one inequality: R + W > N forces the read and write replica sets to intersect, so a quorum read sees the latest committed write — and the moment you tune below it (R=1,W=2 summing to N, or W=1), stale reads and lost writes become legal, not bugs. QUORUM (W=2,R=2 at N=3; W=3,R=3 at N=5) is the production default because it keeps overlap while tolerating one (or two at N=5) node down on both paths, unlike ALL. R is also a p99 knob — a quorum read waits on its slowest required replica, which is why hedging exists. And sloppy quorum buys write availability during partitions by parking writes on hint-holders outside the read set, suspending overlap exactly when a node is down; read repair and Merkle-tree anti-entropy converge it afterward, usually.