Every distributed database you run — etcd, Consul, Cassandra, CockroachDB, Kafka's controller, MongoDB's replica sets — is quietly organized around one number: the quorum. It decides who may lead, which writes count, what happens when the network splits, and why your cluster has 3, 5 or 7 nodes but somehow never 4. And the entire thing rests on a piece of arithmetic you learned as a child:
A real techdiagrams document — download the JSON and import it into the editor via File → Import.
The one idea: majorities must overlap
A quorum is the minimum number of nodes that must agree before an action counts. For a cluster of N, the classic choice is a majority: floor(N/2) + 1. Why majorities, specifically? Because of one unbreakable property:
Any two majorities of the same cluster share at least one member. Three out of five and another three out of five must overlap — there aren't enough nodes for two disjoint groups of three.
That overlap is the entire trick. If electing a leader requires a majority, two leaders can't be elected simultaneously — the shared node already voted, and it only votes once per term. If committing a write requires a majority, then any future majority contains someone who has that write — nothing acknowledged can be silently forgotten. Split-brain isn't prevented by clever code or fast networks; it's prevented by counting.
The partition, decided by arithmetic
Look at the diagram: a 5-node cluster split 3/2 by a network failure. Nobody tells the two sides what to do — the math does. The left side counts 3 of 5: quorum — it elects, commits, serves. The right side counts 2 of 5: no quorum — it stops accepting writes, deliberately. Clients behind the minority see errors, and that's the design working: better refused than forked. When the partition heals, the minority rejoins and catches up; there is no "merge two divergent histories" problem, because only one history was ever allowed to advance.
This is the concrete meaning of "choosing consistency over availability": the minority's downtime is the price of the majority's safety.
The same overlap, as a dial
Leaderless stores (the Dynamo family) generalize the trick: with N replicas per key, require W acks per write and R replicas per read. The overlap condition becomes R + W > N — every read set must intersect every write set, so every read touches at least one fresh replica. N=3, W=2, R=2 is the workhorse. Slide W down for faster writes or R down for faster reads, and you know exactly which guarantee you sold (our consistency models post places this on the full spectrum — and beware sloppy quorums, where under failure the store takes acks from stand-in nodes: the overlap argument silently stops holding until hinted handoff repairs things).
The practical rules that fall out
Run odd sizes. A 4-node cluster needs 3 for quorum, so it tolerates exactly 1 failure — the same as a 3-node cluster. The fourth node adds cost, replication traffic and zero resilience. 3 tolerates 1, 5 tolerates 2, 7 tolerates 3; beyond 7, quorum latency usually costs more than the resilience is worth.
Quorum ≠ everyone. The leader commits when the fastest majority answers — the slowest nodes are off the critical path (exactly why a lagging follower doesn't stall a Raft cluster).
Two datacenters is a trap. Split nodes 3/2 across two sites and the smaller site can never win; split 2/2 and neither can. Quorum wants three failure domains — and if the third must be tiny, a witness node (a vote-only member holding no data) is the honest budget option.
Losing quorum halts writes — plan for it. The cluster stopping is correct behavior, not a bug; the operational question is how fast you can restore a majority. That's an RTO conversation, not a code one.
Flexible quorums (the Flexible Paxos result) relax even the majority rule: election quorums and replication quorums only need to intersect each other. You can commit with 2 of 5 if elections require 4 of 5 — faster steady-state, riskier elections. A sharp tool; know it exists before you need it.
Watch the arithmetic work
Import the diagram into techdiagrams.net and partition it yourself: move nodes across the split, make it 4/1, make it 2/2-plus-witness. The moment you see a side refuse writes because it can count, quorum stops being trivia and becomes what it actually is — the simplest safety mechanism in distributed systems, and the most load-bearing.