Quorum Reads and Writes Explained

N is the number of replicas a key is stored on. W is the number of replicas that must acknowledge a write before it succeeds. R is the number of replicas a read must query before returning a result. The system is quorum-consistent when W + R > N — that inequality guarantees any read set and the most recent write set share at least one replica, so a well-behaved read can always find the latest acknowledged value among the responses it collects.

For cart-77 on 3 replicas, W = 2, R = 2 gives W + R = 4 > N = 3: any 2-of-3 write and any 2-of-3 read must overlap by at least one node. This is weaker than it sounds — the read still has to compare the versions it receives and pick the winning one; the overlap guarantees the latest write is among the responses, not that it arrives first or alone.

This builds directly on strong vs eventual consistency: quorum overlap is the mechanism strong consistency uses, but a Dynamo-style quorum store is not automatically linearizable — that distinction matters enough that it gets its own section further down.

Strict quorum — W and R both a strict majority of N (e.g., W = R = 2 of 3) — balances write and read latency and tolerates one replica being unreachable on either path, because there is still a majority left to satisfy the requirement. This is the default most teams should start from.

Read-optimized (W = N, R = 1) makes every write wait for all replicas, so any single replica alone always has the latest value — reads are fast and cheap, but a write fails outright if even one replica is down, and there is zero write availability during a single-node outage. Write-optimized (W = 1, R = N) flips it: writes return as soon as one replica accepts, so writes stay available almost no matter what, but every read must query all replicas and reconcile before returning, and read latency is bounded by the slowest replica.

None of these is "the correct one." A cart-add is usually read-optimized-tolerant (reads happen constantly at checkout; occasional write retries are cheap), while a payment-confirmation write usually needs the opposite: never lose the write, tolerate slower reads. Choose W/R per operation, not once for the whole database.

A strict quorum only counts acknowledgments from cart-77's designated replicas (A, B, C). If two of those three are unreachable, a strict-quorum write fails outright even though healthy nodes exist elsewhere in the cluster. A sloppy quorum relaxes that: if fewer than W of the preferred replicas are reachable, the coordinator writes to the next healthy nodes in the cluster instead, just to hit the W count and keep the write available.

Those substitute nodes store the data as a hint — a temporary write labeled "this belongs to node C, hand it off once C is reachable again." Hinted handoff is the background process that detects when the rightful replica comes back and transfers the hinted data to it, after which the substitute node can discard its copy.

Sloppy quorums buy availability at a real cost: durability now depends on a temporary node correctly holding and later delivering a hint, not on the cart's designated replica set. A monitoring gap here — no alert on a growing hint backlog, no limit on how long a hint can sit unhanded — turns a temporary availability trade into a silent data-loss risk.

A quorum read queries R replicas and can legitimately get back different versions of cart-77 — one replica may have missed a write, or a sloppy-quorum hint may not have been handed off yet. The coordinator must reconcile these into one answer using a version marker: a timestamp for last-write-wins, or a vector clock when the store needs to detect true concurrent writes instead of guessing from a clock.

Read repair pushes the winning version back to any replica that responded with a stale one, during the same read — so the next read on that key is more likely to be consistent without waiting for a separate background pass. It is opportunistic, not scheduled: it only fixes what the current read happened to touch.

Because read repair depends on a read actually happening, rarely-read keys can stay divergent indefinitely. Production quorum stores pair it with anti-entropy — a scheduled background comparison (often Merkle trees) that finds and fixes divergence across the whole keyspace, not just the keys clients happen to query.

Trigger. During a rolling deploy, nodes B and C both restart within the same maintenance window — a violation of the "only one node down at a time" assumption the on-call team had in their head but never enforced. A write to cart-77 (W = 2) can't reach a strict quorum of {A, B, C}, so the coordinator falls back to a sloppy quorum: A acknowledges, and node D — outside cart-77's preference list — accepts a hint intended for C.

Symptom. Node C is decommissioned as part of the same deploy (replaced, not just restarted) before the hint on D is handed off. The item silently never appears in cart-77's canonical replica set; a customer sees an empty cart after the deploy window.

Root mechanism. Hinted handoff assumes the intended node eventually comes back with the same identity. Decommissioning breaks that assumption — D's hint has nowhere valid to hand off to, and nothing forced D to promote the hint to a real replica write instead. Evidence: D's hint log shows an entry for cart-77 targeted at node-C with no handoff timestamp, and a cluster membership change removing node-C at a later log time than the hint. Recovery: replay hints targeting decommissioned nodes onto the current preference list before finalizing decommission. Prevention: block node decommission while it has undelivered hints targeted at it, alert on hint age past a threshold, and require deploy runbooks to keep at least a strict quorum of the original replica set reachable at every step.

Dynamo-style N/W/R quorums and Raft/Paxos consensus quorums both use the word "quorum," but they guarantee different things. A consensus quorum elects one leader and orders every write through it, giving true linearizability. A Dynamo-style quorum has no single leader — multiple coordinators can accept concurrent writes to the same key, so W + R > N guarantees overlap in who has a copy, not a single global order of writes. Don't reach for W=R=majority expecting Raft-grade guarantees; it is closer to "probably consistent, provably converging" than "provably linearizable."

Choose strict quorums as the default, and move toward sloppy quorums only where write availability during a partition matters more than strict placement — and only with hint-backlog monitoring in place, not as a silent fallback. Choose W/R per operation from what a stale or lost value costs: cart contents tolerate a brief lag; payment confirmations do not.

If an operation genuinely needs linearizability — a real single global order, not just eventual convergence — a Dynamo-style quorum is the wrong tool regardless of how W and R are tuned; reach for a consensus-backed store or a single-leader path for that specific key instead.