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.

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.