A node that cannot reach its peers has the same problem a timeout has. Either the peers are gone, or the peers are fine and the path between you is not. Nothing it can observe tells those two cases apart.
So consider an election rule that sounds sensible: if you cannot reach the leader, elect a new one. The course's script split_brain_majority.py runs that rule on five nodes, where a majority would be three, and splits them with a partition.
The unsafe trace
5 nodes, majority = 3. Partition splits them 2 | 3.
LEFT 2 nodes, 2 votes >= 1 needed -> ELECTS n1 (term 1)
RIGHT 3 nodes, 3 votes >= 1 needed -> ELECTS n3 (term 2)
n1 commits 'set balance = 300'
n3 commits 'set balance = 500'
** SPLIT BRAIN: 2 leaders in one cluster, 2 conflicting commits **
Both leaders behave correctly. Each has a quorum of the nodes it can see, each accepts writes, and each is right by its own information. When the partition heals, one customer's money is going to be wrong.
Why better detection is not the fix
It is tempting to respond with a smarter failure detector. The course's answer is that failure detection cannot be made accurate. That ambiguity is at the root of the FLP result, and it is the same one a timeout had in the first course. A slower or cleverer detector still cannot distinguish a dead peer from a silent one.
Common Mistake
Treating a split brain as a monitoring problem. If the rule lets any group that can see itself elect a leader, tuning the timeouts only changes how often the split happens, not whether two groups can both commit.
What the arithmetic says
The fix is to make it impossible for two groups to both commit decisions, and the course says there is exactly one way to do that with counting. Read the trace again with five nodes and a majority of three: the rule asked for one vote, and that is what let a two-node side elect a leader. A rule that needs three of five cannot be satisfied by both sides of a split at once, because three plus three is more than five. The next section of the course builds that rule into a protocol.
