Single-decree consensus decides a value only with a strict majority of acks. Partition a 5-node cluster 3–2: the 3-side reaches majority (3 ≥ 3) and decides; the 2-side has 2 < 3 and blocks. Then the twist — going 3 → 5 → 7 nodes raises failures tolerated (1 → 2 → 3) but the majority grows too (2 → 3 → 4 acks per decision), so a single decision does more work, not less.
Single-decree consensus decides a value only when a strict majority of the cluster acknowledges it — floor(n/2)+1 acks, never fewer. Partition a 5-node cluster 3–2 and the asymmetry is total: the 3-node side reaches majority (3 ≥ 3) and decides; the 2-node side has 2 < 3 acks and blocks — it can't decide, and can't even tell whether the other side already did. Then the counterintuitive part: going 3 → 5 → 7 nodes raises the failures tolerated (1 → 2 → 3) but the majority grows too (2 → 3 → 4 acks per decision), so a single decision does more work as the cluster grows, not less. "More replicas = more throughput, and my minority partition keeps serving" is wrong on both counts.
Designing Data-Intensive Applications, 2nd ed. (Kleppmann & Riccomini, 2025), Chapter 10 — Consistency and Consensus, §"Single-value consensus" / §"Pros and cons of consensus":
only the majority portion of the network can make progress.
The book presents consensus (single-decree, Paxos/Raft-style) as safe under partition precisely because a decision requires a majority, and any two majorities of the same cluster overlap. Here you watch that overlap force exactly one side to make progress — and watch the majority requirement make each decision heavier, not lighter, as you add nodes.
The result is carried by one idea: a strict majority. These help; each line notes where it shows up.
floor(n/2)+1 acks, the smallest set such that any two such sets share a node. It shows up as majority() and the acks >= quorum test in propose().BLOCKED, not a wrong value.cluster.decided value existing after both proposals.A majority is the smallest set of nodes such that any two majorities of the same cluster must overlap in at least one node. For n = 5, majority = 3, and any two 3-subsets of 5 share a node — there's no room for two disjoint majorities. That single overlapping node is what makes split-brain impossible: it can't ack two conflicting values, so two majorities can never decide differently.
The consequence for a partition is immediate. Split the cluster and at most one side can hold a majority. That side has enough acks to decide. The other side — the minority — is not missing permission, it is missing nodes: it physically cannot assemble floor(n/2)+1 acks, so it must wait. It also can't distinguish "the other side decided" from "the other side is down," so it can't safely guess.
The whole thing is one script, code/majority_quorum.py, exposing a single Cluster.propose(value, reachable) that decides iff len(reachable) >= majority.
cd study/ddia/ch10/code
python3 majority_quorum.pyDo not read the output yet — make each prediction first.
Predict. A 5-node cluster splits into a 3-node side and a 2-node side. Majority is 3. Which side (if any) can decide a value — and what does the other side do?
The 3-side decides x=BIG; the 2-side collects only 2 of the 3 required acks and blocks. Exactly one value is ever decided.
Predict. For n = 1, 3, 5, 7: what is the majority, and how many node failures can the cluster survive and still form a majority from the rest?
Failures tolerated climbs 0 → 1 → 2 → 3. More nodes really do buy more availability — this half of the intuition is right.
Predict. Same n = 3, 5, 7. Each decision needs a majority round-trip. How many acks does one decision require at each size — does a decision get cheaper as the cluster grows?
Acks per decision rise 2 → 3 → 4. A single decision does more work at n=7 than at n=3 — the exact opposite of "add nodes to go faster."
x=BIG — is ever decided.floor((n-1)/2)); an even n adds nothing over the odd below it.floor(n/2)+1) — it grows with n, so a single decision never gets cheaper by adding nodes.The lever behind all three results is one property of majorities: any two majorities of the same cluster intersect. A majority is floor(n/2)+1 nodes; two disjoint majorities would need 2 · (floor(n/2)+1) > n nodes, which the cluster doesn't have. So there is always at least one node in both — and that shared node cannot acknowledge two conflicting proposals. This is the whole safety argument: two majorities can never decide different values, so a decision, once made, is final and unique. Split-brain is not prevented by good behavior; it is prevented by arithmetic.
That same arithmetic is why only the majority side of a partition proceeds. A partition carves the cluster into groups whose sizes sum to n; at most one group can be a majority (two would have to overlap, but a partition means they don't). The majority side has enough acks and decides. The minority side isn't waiting for permission — it is short of nodes, unable to assemble floor(n/2)+1 acks no matter how long it tries, and unable to tell a decided-elsewhere cluster from a dead one. It keeps safety (it never decides a wrong value) at the cost of liveness (it decides nothing). That is the trade the book names: only the majority portion can make progress.
And it is why adding nodes doesn't speed anything up. Every decision must contact a majority, and the majority is floor(n/2)+1, which grows with n: 2, 3, 4 for n = 3, 5, 7. So going from 3 to 7 nodes doubles the failures you tolerate but also raises the acks each decision waits on from 2 to 4. Per-decision work rises monotonically in n; a single decision gains nothing and typically loses (more nodes to hear from, more tail latency). Consensus throughput is flat-to-declining in n — the replicas are there for availability, not speed.
Qw and a read quorum Qr with Qw + Qr > n, then shrink Qw below the majority and see reads still overlap every committed write — the generalization behind w + r > n and why "majority" is just the symmetric special case.Sources: DDIA 2e, Ch. 10, §"Single-value consensus", §"Pros and cons of consensus" · Ongaro & Ousterhout, "In Search of an Understandable Consensus Algorithm" (Raft, 2014).