Leader election needs a majority

Tue, 21 Sep 2027 00:00:00 +0000

Majority quorum is what forbids a split brain. When the cluster is partitioned, the side with fewer than half the nodes cannot form a quorum or stay authoritative.

One leader, many votes

A replicated system that must not diverge elects a single leader for a term. A candidate asks peers for a vote, and to become leader it needs a quorum, more than half of the voting members in a fault-tolerant scheme, to say yes within a term. That majority is what lets the winner act with confidence that no split-off minority can out-vote it, so the group can make decisions with one authority at a time. Exactly half is not enough: quorums are defined as strictly more than half, which is what makes two halves never both be authoritative.

Quorum kills split brain

Partitioning is the failure that leader election exists to survive. If a cluster is split into two halves, at most one half can hold a majority; the minority cannot form a quorum, so it is forced to wait rather than accept writes it could not back. That is the whole point: an old leader on the minority side is safely replaced, and two partitions never both think they own the data and write divergently. The majority rule is what turns ‘who is in charge’ from a guess into an operation with a single, safe answer.

Terms and ticks keep it tidy

Leadership has to be re-proved, not assumed forever. Terms and heartbeat ticks bound how long a leader is trusted: a leader renews its lease by staying visible, and when the ticks lapse because it died or the network cut, followers start a new election and a new term. That constant renewal is what lets the group cope with machines joining and leaving, because no leader’s authority depends on staying alive forever. The result is a loop, elect, renew, detect loss, re-elect, which keeps the group honest without anyone needing to agree on a single absolute clock.

When it breaks

An even-sized cluster learns this rule the hard way. Four nodes split into two pairs need three votes to elect anyone, so neither pair can produce a leader and the cluster goes quiet until the partition heals. Six nodes split three against three deadlock the same way. That is why production clusters usually run three or five voters: any partition leaves at most one side holding a strict majority.

A side without a majority must stop accepting writes, and that stall is the price of safety. The old leader stranded on the minority side steps down once it can no longer renew its quorum, so clients pinned to that side see errors instead of progress. Treating those errors as a bug and forcing a local write reintroduces exactly the split brain the majority rule was bought to prevent.

Elections can also livelock with no partition at all. Candidates starting in the same instant split the vote so nobody reaches a majority, terms churn, leadership flaps, and write latency spikes while every ballot fails. Randomized election timeouts exist to break this symmetry, so identical fixed timeouts or saturated nodes that delay votes reproduce the storm on demand.

The last trap is term regression. A node returning from a long partition campaigns on a stale term, or a candidate with a lagging log asks for votes it has not earned. Voters must reject lower terms and demand an up-to-date log; skipping that freshness check elects a leader that then overwrites entries a previous majority had already committed.

Check it quickly

Save this as majority.py and run python3 majority.py. It uses only the Python standard library and models five voters with one ballot each per term, plus a partition that decides whose votes a candidate can actually collect:

def quorum(n):
 """Strict majority: more than half of all voters, not of one side."""
 return n // 2 + 1


class Cluster:
 """Minimal ballot box: N voters, one vote per node per term."""

 def __init__(self, size):
 self.size = size
 self.terms = [0] * size
 self.voted_for = [None] * size

 def request_votes(self, candidate, term, reachable):
 if term <= self.terms[candidate]:
 return [] # stale term: the candidate itself has seen newer
 votes = []
 for node in reachable:
 if term > self.terms[node]:
 self.terms[node] = term
 self.voted_for[node] = candidate
 votes.append(node)
 elif term == self.terms[node] and self.voted_for[node] in (None, candidate):
 votes.append(node)
 return votes

 def elect(self, candidate, term, reachable):
 votes = self.request_votes(candidate, term, reachable)
 return len(votes) >= quorum(self.size), votes


assert quorum(3) == 2 and quorum(4) == 3 and quorum(5) == 3

majority = Cluster(5)
won, votes = majority.elect(candidate=0, term=1, reachable=[0, 1, 2])
assert won and sorted(votes) == [0, 1, 2], votes
print(f"5 nodes, side of 3: elected with votes {sorted(votes)} (need {quorum(5)})")

minority = Cluster(5)
won, votes = minority.elect(candidate=3, term=1, reachable=[3, 4])
assert not won and sorted(votes) == [3, 4], votes
print(f"5 nodes, side of 2: no leader with votes {sorted(votes)} (need {quorum(5)})")

even = Cluster(4)
for candidate, reachable in ((0, [0, 1]), (2, [2, 3])):
 won, votes = even.elect(candidate, term=1, reachable=reachable)
 assert not won, (candidate, votes)
print(f"4 nodes split 2-2: neither side reaches {quorum(4)}, cluster stalls")

fresh = Cluster(5)
won, _ = fresh.elect(candidate=0, term=2, reachable=[0, 1, 2, 3, 4])
assert won
won, votes = fresh.elect(candidate=4, term=1, reachable=[0, 1, 2, 3, 4])
assert not won and votes == [], votes
print("stale term 1 after term 2: rejected with zero votes")

print("PASS: majority side elects, minority and even split stall, stale term loses")

The script asserts the election semantics directly. The three-node side gathers three of five votes and elects a leader for the term, while the two-node side stalls at two and elects nobody. The even split replays four nodes cut two against two: neither side reaches three, so no leader emerges and the cluster waits. A stale-term ballot is rejected with zero votes even though the arithmetic alone would pass. Expect this output:

5 nodes, side of 3: elected with votes [0, 1, 2] (need 3)
5 nodes, side of 2: no leader with votes [3, 4] (need 3)
4 nodes split 2-2: neither side reaches 3, cluster stalls
stale term 1 after term 2: rejected with zero votes
PASS: majority side elects, minority and even split stall, stale term loses

The assertions passed with Python 3.12 on macOS. The model covers vote counting and term freshness only, not log replication, durable state, or randomized timers; for those rules, read the Raft paper’s election section next.

Sources

In Search of an Understandable Consensus Algorithm (Raft), leader election and majority quorum in section 5, checked 2026-09-09.
etcd: etcd versus other key-value stores, leader election and distributed coordination over Raft, checked 2026-09-09.
ZooKeeper Internals, majority quorums for atomic broadcast and leader election, checked 2026-09-09.

Election · XB Field Notes