A network partition splits a distributed database cluster. Both halves keep accepting writes. When the partition heals, the cluster holds two incompatible histories at the same log index. There is no safe way to merge them. Someone's committed write has to disappear.
This is FM12 — Split-Brain. It is the failure mode consensus algorithms were built to prevent.
What the failure looks like in production
Picture a five-node cluster spread across two data centres. Three nodes sit in DC1. Two sit in DC2. The link between them drops.
The three nodes in DC1 can still see each other. They elect a leader among themselves. They keep committing writes. From their perspective, DC2 has failed.
Without a rule preventing it, the two nodes in DC2 do the same thing. They cannot see DC1. They elect a leader among themselves. They keep committing writes. From their perspective, DC1 has failed.
Now two nodes call themselves the leader. Two disjoint sets of writes commit at the same log indices. When the network heals, the cluster has two incompatible logs. Both were acknowledged to clients. Both are on disk.
There is no algorithm that reconciles them without discarding real committed data.
Why the majority quorum rule exists
Consensus algorithms prevent this exact scenario by requiring a majority for every commit. In a five-node cluster with a three-two partition, only the group of three can make progress. The group of two is unavailable.
This is the rule that matters: the group of two cannot commit anything. It cannot know whether the group of three has committed entries that it does not have. So it must refuse to commit new entries.
The design prevents split-brain at the cost of partition availability. That cost is not incidental. It is the entire point.
This is AT1 — Consistency vs Availability. Consensus algorithms are CP systems. They halt new commits during majority loss. The invariant they preserve is simple: committed entries are never overwritten.
The structural reason it cannot leak
Two nodes cannot both hold a majority in the same cluster at the same time. That is the mathematical reason split-brain does not happen under the majority rule.
Any new leader must win votes from a majority. That majority must include at least one node that holds every committed entry. The check ensures the new leader inherits the full committed history before accepting new writes.
Every commit path passes through the same majority test. A minority partition cannot form a competing history because it cannot form a competing majority. The rule is not a heuristic. It is arithmetic.
The timing assumption underneath
From outside, a slow node looks identical to a crashed node. There is no oracle that answers "is this node alive?" correctly in all cases.
Consensus algorithms work around this with timeouts. If a node does not respond within T milliseconds, others act as if it is gone. This is not a solution. It is an assumption about timing.
If T is too short, correct nodes get treated as failed. If T is too long, crashed nodes delay every commit.
Real consensus algorithms accept this by giving up one of two properties during pathological network conditions. The two properties are liveness — consensus always terminates — and safety — consensus is always correct. The algorithms choose safety.
Under a persistent partition, they may not terminate at all. When they do terminate, the result is correct.
Split-brain would be a safety violation. It never happens. Unavailability is a liveness violation. It happens whenever the majority is unreachable.
Where split-brain still creeps back in
The majority quorum rule is a structural guarantee. Implementations can still undermine it.
Membership changes without joint consensus. Adding or removing nodes from a consensus cluster requires a joint consensus phase. Skipping this phase — adding or removing nodes one at a time — can briefly create two disjoint majorities during the transition. That transient window is enough for split-brain.
Reading from followers without leases. Basic consensus routes all reads and writes through the leader. Followers hold stale data. Reading from followers gives you higher throughput and lower consistency. Lease-based reads let the leader answer without contacting followers by holding a time-bounded lease. If your clock assumptions break, two nodes can hold overlapping leases.
Multi-group rebalancing. Some systems run one consensus group per key range. Splitting a range under partition can leave a key temporarily addressable in both the old and the new group.
Each of these is a place where an engineer choosing operational convenience over the majority rule can reintroduce the exact failure mode the algorithm was designed to prevent.
The cost you pay for the guarantee
The majority quorum has a latency price. Every write committed through consensus requires at least one round trip to a majority of nodes. When the cluster spans data centres, write latency includes the network RTT to the farthest member of that quorum.
A single write that takes 1ms on a single-machine database can take 30ms when the quorum spans regions. This is FM5 — Latency Amplification as a direct consequence of the FM12 defence.
Node placement determines who pays. Put two nodes in DC1, two in DC2, one in DC3. A majority of three can form without touching DC3. Commit latency is bounded by the DC1–DC2 link.
Lose DC1 or DC2 and DC3 has to participate. Latency jumps to the cross-region RTT.
Neither DC1 alone nor DC2 alone can form a majority. Split-brain remains impossible. Availability during a two-DC outage remains impossible. That is not a bug. It is the tradeoff written in the design.
The signal that tells you this applies to your system
You see it whenever a distributed database reports "leader unavailable" during a network event. You see it whenever write latency jumps by the cross-data-centre RTT after a regional failure. You see it whenever an orchestration cluster stops accepting API changes because its consensus store cannot form a quorum.
That "unavailability" is the algorithm doing its job. The alternative is accepting writes on both sides of a partition. That is the failure mode you never want to debug at 3 AM.
If your system happily keeps writing on both sides of a partition, it is not using consensus. It is deferring the split-brain to reconciliation time. Someone downstream will have to pick which committed writes survive and which vanish.
The harder question
Consensus prevents split-brain within a single consensus group. Real production systems run many consensus groups — one per shard, one per key range, one per tenant. Cross-group operations are not covered by a single consensus decision.
When a transaction reads from one consensus group and writes to another, what protocol ensures that neither group commits its half unless both do? What happens when the coordinator of that protocol crashes mid-decision? Which side of the partition wins when the two groups disagree about whether the transaction committed?
The answer is not another round of the same algorithm. It is a separate distributed transaction protocol layered on top. That layer has its own failure modes, its own latency cost, and its own subtler forms of split-brain.
The full framework treatment — compression blocks, three-level exercises, and the complete AT/FM mapping — is in the Reference Book, Chapter 7 (Failure Modes, FM12). Free chapter available at computingseries.com/books/ref.