Leader Election

Every distributed system faces a fundamental question: who is in charge? When multiple servers need to coordinate, having a single leader dramatically simplifies the problem. The leader makes decisions, handles writes, and ensures everyone stays synchronized. But leaders fail. Networks partition. Clocks drift. And suddenly that simple question becomes one of the hardest problems in distributed computing.

Leader election is the process of choosing a single node to act as the coordinator. We have seen how Raft handles this through its term-based election mechanism. But leader election appears everywhere in distributed systems, often in contexts that have nothing to do with consensus algorithms. Your database needs to elect a primary. Kafka needs to elect partition leaders. Kubernetes controllers need to elect which instance handles reconciliation. Even simple job schedulers need someone in charge.

The consequences of getting leader election wrong are severe. If two nodes both think they are the leader (split-brain), they make conflicting decisions, corrupt data, and cause inconsistencies that can take days to untangle. If no node thinks it is the leader, the system stalls and nothing happens. The sweet spot, exactly one leader at all times, is surprisingly hard to achieve.

This chapter explores leader election as a general problem. We will examine different approaches, understand their trade-offs, and see how production systems implement leader election. By the end, you will understand not just how leader election works, but when to use which approach and what pitfalls to avoid.

This chapter builds on the consensus foundations from earlier chapters. Understanding Paxos and Raft will help you appreciate why some leader election approaches are stronger than others.