Leader Election
The problem
Some coordination tasks (assigning work, sequencing writes) are simplest if exactly one node is temporarily in charge — but that leader can crash at any time, and the remaining nodes need a reliable way to agree on a replacement without ending up with two leaders acting simultaneously.
Why now
Consensus algorithms already provided the general mechanism for machines agreeing under failure; leader election is that mechanism applied to one specific, extremely common question — 'who is currently in charge' — making it a direct, practical application rather than a separate theoretical topic.
Mental model
Leader election is consensus with a narrow question: nominate a candidate, get a majority of votes, become leader for a term. The 'majority' requirement is what prevents split-brain — two simultaneous leaders — because two disjoint groups can't both contain a majority of the same cluster at once.
Requires
- Consensus AlgorithmsDistributed Systems
Leader election is a direct application of consensus to the specific decision 'which single node leads'; you need the general majority-agreement mechanism already understood before its specialization to leadership is meaningful.
Related
Used in
- Database primary/replica failover, promoting a new primary when the old one dies
- Kubernetes' own control plane, which uses leader election among its controller manager instances
- Distributed cron/scheduling systems, ensuring only one instance runs a given scheduled job
- ZooKeeper and etcd, commonly used as off-the-shelf leader election primitives for other systems
Projects
- Implement a basic leader election among three simulated nodes using a simple majority-vote protocol, including handling a leader crash and re-election
- Explain, with a diagram, exactly how a network partition could create a split-brain scenario if a majority requirement weren't enforced
Examples
- A database replica set with one primary and two secondaries elects a new primary automatically if the current primary stops responding
- Two application instances both believing they're the 'leader' and both writing to the same resource is a split-brain bug caused by insufficient election guarantees
Resources
Mastery checklist
- I can explain why leader election requires a majority vote, not just any vote
- I can explain what split-brain is and how majority requirements prevent it
- I can implement a basic leader election protocol among simulated nodes
- I can identify a real system that relies on leader election and what it uses the leader for