2026-05-23
You have five database replicas. A client writes a value. How many replicas must confirm the write before you call it "durable"? How many must you read from to guarantee you see the latest value? The naive answer — "all of them" — kills availability the moment one node hiccups. The correct answer is quorum: require a majority, not unanimity.
The math is elegant. With N replicas, a write quorum W and read quorum R, you get strong consistency if and only if W + R > N. Why? Because any read set and any write set must overlap by at least one node — and that overlapping node has seen the latest write.
Concrete example: Dynamo-style systems like Cassandra and Riak let you tune this per-request. With N=5:
The sweet spot for most workloads is W = R = (N/2) + 1 — a simple majority. With N=5 that's W=R=3. You tolerate 2 failures, guarantee consistency, and balance read/write latency.
Why odd N matters: With 4 nodes, a majority is 3 — same as 5 nodes, but you've added a node that can fail without buying any extra fault tolerance. Always run quorum clusters with odd numbers: 3, 5, 7. That's why etcd, Consul, and ZooKeeper deployments are almost always 3 or 5 nodes.
The latency trap: Quorum latency is bounded by the slowest node in the quorum, not the slowest overall. With N=5, W=3, your write waits for the 3rd-fastest ack. This is why P99 latency in quorum systems is dominated by tail latency — one slow disk drags everything. Hedged requests and "speculative" reads to extra replicas can help.
Rule of thumb: If you can tolerate f failures and need consistency, you need 2f + 1 nodes. Want to survive 1 failure? 3 nodes. Two failures? 5 nodes. There is no cheaper way — this is a mathematical floor, not an engineering choice.
Quorums are how Raft elects leaders, how Paxos commits values, and how every serious distributed database avoids split-brain. Understand the W+R>N inequality and you understand half of distributed systems.