How Many Have to Answer

Piece 027 explained why a majority is enough for consensus: any two majorities of the same group must overlap, so a value only one majority agreed to can't be silently contradicted by another. Quorum reads and writes, the mechanism behind Dynamo, Cassandra, and Riak, reuse that exact overlap arithmetic — but they answer a smaller, different question, and it's worth being precise about which one.

N, W, and R

Start with a key replicated across N nodes. A write is considered successful once W of those N replicas have acknowledged it — not all N, which would make the write only as fast as the slowest replica and unavailable the moment any one node is down. A read is considered successful once R replicas have answered, and the client picks the freshest of those R answers (freshness decided by a timestamp or version number attached at write time). Both W and R are dials the client sets per operation, not fixed properties of the system — the same store can serve one request with W=1 for speed and another with W=N for durability, depending on what that particular write is worth.

Why R + W > N is the whole trick

Here's the overlap argument, and it's genuinely the same shape as piece 027's majority proof even though it's proving something else. If a write quorum of size W and a read quorum of size R were drawn from N replicas with zero nodes in common, they would together account for W + R distinct nodes — but if W + R > N, there aren't W + R distinct nodes to draw from, so the two sets are forced to share at least one. That shared node saw the write and will answer the read: the read quorum is guaranteed to include at least one replica holding the value the write quorum just committed. Set R=1, W=N and reads are cheap but writes wait on every replica; set R=N, W=1 and it's the reverse; the common middle ground — R and W both a bare majority of N — is what most quorum stores default to, trading a little latency on both sides for tolerating some replicas being slow or down on either operation.

What the overlap guarantee doesn't give you

Getting an answer from a node that saw the latest write isn't the same as knowing which of several answers is the latest write. Nothing stops two writes from racing to different, non-overlapping subsets of replicas before either finishes — the guaranteed overlap just means a subsequent read quorum will see at least one copy of each. Picking the winner among conflicting copies needs a way to order them: a wall-clock timestamp (Dynamo's original last-write-wins, simple and occasionally wrong), or a vector clock (piece 026) that can tell genuine causal order from real concurrency and hand true conflicts to the application instead of guessing. The quorum mechanism guarantees you'll see the conflict; it was never going to resolve it for you.

What it isn't

It's tempting to fold this into consensus (027) since both rest on the same "any two large-enough sets must intersect" fact, but they answer different questions at different scopes. Consensus elects one agreed value or leader for the whole cluster, ongoing, coordinated, expensive — Raft's leader has to stay elected and its log has to stay ordered. A quorum read or write is a per-key, per-request choice with no coordinator and no election: each operation just contacts enough replicas and stops, and different requests for the same key can use different R/W without asking permission from anything. It's also not two-phase commit (039) — nothing here blocks waiting for a coordinator's final word, and a slow or dead replica outside the quorum size just gets left behind rather than stalling the operation. And a sloppy quorum — writing to whichever W nodes happen to be reachable, even if they're not the key's "correct" replicas, backed by hinted handoff (piece 053) to forward the write later — deliberately gives up the strict overlap guarantee entirely in exchange for never rejecting a write just because the right nodes are unreachable. Dynamo runs that trade by default; it's availability bought by spending the one thing quorum reads/writes were built to guarantee.

Why this repository has never needed a dial

Every mechanism in this piece exists because N is greater than one — because there's more than one copy of the data and someone has to decide how many of those copies get consulted before an operation counts. This repository has exactly one working copy of its own state at a time; there's no second replica to write to concurrently and no R/W to tune, the same "no multiplicity to manage" absence pieces 026, 031, 039, 043, 050, 056, and 057 have each named from a different angle. GitHub keeps its own replicated copies underneath, but that replication is invisible here by design, one more layer this repository consumes finished rather than one it has ever had to build.