Quorum

In a system that keeps multiple copies of the same data for durability, you cannot wait for every copy to respond on every operation. Some node is always slow, restarting, or unreachable. A quorum is the agreement rule that lets you make progress anyway: you decide how many of the copies have to say yes, and you ignore the rest.

The classic setup uses three numbers. N is the number of replicas holding a piece of data. W is how many of them must acknowledge a write before you call it committed. R is how many you read from before you trust the answer. A common choice is N=3, W=2, R=2.

The key formula is W + R greater than N. When that holds, the set of nodes that confirmed the latest write and the set of nodes you read from must share at least one node, because two subsets of N nodes whose sizes add up to more than N cannot be disjoint. That shared node carries the newest value, so a correct read always sees it as long as you pick the highest version.

On a write, a coordinator node sends the new value to all N replicas in parallel but only waits for W acknowledgements. Each value is tagged with a version, usually a logical timestamp or a vector clock, so replicas and readers can tell which copy is newer. Once W replicas confirm, the write returns success even if the remaining replicas have not applied it yet.

On a read, the coordinator queries R replicas and compares their versions. If they disagree, it returns the newest one and often triggers read repair, quietly pushing the fresh value back to the stale replicas so they catch up.

Tuning W and R lets you slide along a spectrum. W=N, R=1 makes reads fast and writes strict. W=1, R=N flips it. W=2, R=2 with N=3 balances both. You can also break the overlap rule on purpose: W=1, R=1 gives very fast eventual consistency where a read might miss a recent write, which some workloads accept.

Quorums fit any system that replicates data across machines or regions and needs to survive node failures without going fully offline. With N=3 and W=R=2 you can lose one replica and still serve both reads and writes, because two surviving nodes still satisfy the quorum.

The cost is latency. Every quorum operation waits for the slowest of the W or R nodes it needs, so a single lagging replica can drag your tail latency up. Crossing data centers makes this worse because each acknowledgement now pays a network round trip of tens of milliseconds.

Two sharp edges to remember. First, a strict quorum where W + R is greater than N gives you read your writes consistency, not full linearizability on its own; concurrent writes can still produce conflicting versions that the application or a conflict resolver must reconcile. Second, to avoid two halves of a split network both forming a quorum and accepting conflicting writes, the rule W greater than N divided by 2 ensures only one majority can exist at a time.

Picture a user profile stored with N=3 replicas across three machines, configured W=2 and R=2. You update your display name. The coordinator sends the change to all three replicas and waits. Two confirm within 4 ms; the third is busy with garbage collection and lags. The write returns success.

A moment later you load your profile. The read hits two replicas. One of them is a node that confirmed the write, so it returns the new name with version 7; the other still has version 6. The coordinator picks version 7, shows you the new name, and repairs the stale replica in the background.

Now the third replica recovers. It was never required for the quorum, so the system never blocked on it, yet it converges to the right value through replication and read repair. That is the whole point: progress with two out of three, correctness preserved by the overlap, and no global lock anywhere.