Split-brain is one of the most dangerous failure modes in a replicated system. It happens when a network partition cuts the cluster in two, and nodes on each side cannot tell whether the others have crashed or are merely unreachable. If each side decides it should now be the leader, the system ends up with two leaders, each accepting writes independently. When the partition heals, those writes conflict, and there is no longer a single authoritative version of the data.
The risk is built into leader-follower replication. MongoDB’s failover logic shows where it would arise: when a primary “does not communicate with the other members of the set for more than the configured electionTimeoutMillis period,” a secondary calls an election to make itself primary. The danger is the old primary believing it is still in charge on the other side of a partition.
The standard defense is to require a majority. MongoDB only promotes a new primary by election among the members that can still reach each other, so a minority side cannot elect its own primary; the partition that lacks a majority steps down to read-only rather than competing. This is the deeper reason consensus algorithms insist on a quorum: a majority can exist on only one side of any partition, so allowing only a majority to act prevents two leaders from coexisting. Related techniques are leases, which give a leader time-limited authority that expires, and fencing, which rejects writes from a leader that has been superseded.
Martin Kleppmann’s analysis of consistency labels underscores why this matters. He observes that under a partition, “single-leader replication is not CAP-available” because clients cut off from the leader cannot write. Refusing to let an isolated minority keep accepting writes is the price of avoiding split-brain, and it is a deliberate trade of availability for correctness.