# Leader election > Leader election chooses one node to coordinate a particular job, such as accepting writes for a partition or scheduling work. In distributed systems, choosing a replacement is only half the problem: the design must also stop an old leader from continuing to act after losing authority. Source: https://sysround.com/concepts/leader-election Updated: 2026-11-05 ## How leader election works First define the scope of leadership. A replicated log might have one leader per partition, while a small control plane might have one active controller. Leadership should cover only the work that needs a single authority; other work can run in parallel. Use a proven coordination mechanism rather than having nodes independently declare themselves leader. For example, Raft candidates request votes, and a candidate needs a majority to become leader for a numbered term. In a three-member group, two votes are required, and voting rules restrict which candidates can win. The leader sends heartbeats or renews a lease to show that it is still active. Missing heartbeats trigger an election or lease expiration, but they do not prove the old leader is dead: a network partition or long process pause can look like a crash. Randomized election timeouts help candidates avoid repeatedly splitting the vote. Protect the actual work, not just the election record. When using an external coordinator, give each new leadership grant a monotonically increasing fencing token. Before the new leader performs protected operations, the target resource must establish the new token and reject operations carrying older tokens; a token that nobody checks provides no protection. Election also needs a recovery policy. A new replicated-log leader must preserve committed entries before accepting new writes, and a new scheduler must recover pending work from durable state. Raft integrates election with log-safety rules, but its terms do not automatically fence unrelated databases, workers, or external APIs. ## Worked example: Fencing a control-plane leader Three controller replicas manage database upgrades using a three-node consensus-backed coordinator. Controller A holds leadership generation 41 and sends commands through a management agent. A pauses long enough for its lease to expire. B acquires generation 42, installs it at the agent, and waits for confirmation before issuing upgrade commands. The agent durably records 42 and rejects later commands carrying 41. When A resumes, its delayed command cannot start a conflicting upgrade. B still reconciles any operation that began before fencing took effect; election does not undo existing work. If the coordinator loses its two-node majority, no new leadership grant is issued, so new upgrades wait. ## Trade-offs - **Safety can require stopping work.** A majority-based design must stop authorizing new work when it cannot reach a quorum rather than let both sides of a partition make conflicting decisions. - **Faster failover can mean more false elections.** Short detection timeouts reduce recovery delay but make ordinary latency spikes and process pauses more likely to trigger leadership changes. - **Leadership can become a bottleneck.** One leader simplifies ordering, but scaling often requires partitioning leadership instead of routing every operation through one global node. - **Fencing requires cooperation from the target.** The protected storage or execution endpoint must enforce leadership generations, and external services may offer only idempotency rather than fencing. - **Coordination adds an operational dependency.** A coordination service needs durable state, safe membership changes, monitoring, and recovery procedures of its own. - **Election does not finish recovery.** State catch-up, reconciliation, and client rerouting can delay useful service even after a new leader has been chosen. ## When to use it in a system design interview - A replicated partition needs one authority to order writes and safely replace that authority after failure. - Multiple controller replicas must coordinate failover, upgrades, or ownership changes without issuing conflicting commands. - A scheduler needs one active dispatcher per shard, with standby replicas ready to recover durable scheduling state. - The interviewer asks what happens when the current owner pauses, becomes unreachable, or returns after another node takes over. ## How to bring it up in the interview - Start with the invariant: for example, only the current partition leader may commit ordered writes. Define whether leadership is global, per tenant, or per partition. - Name the implementation boundary: use an existing database or consensus-backed coordinator for election rather than proposing a custom heartbeat-and-vote protocol. - Walk through a paused-leader scenario: leader A pauses, B takes over, and A resumes. Explain exactly where A's stale operations are rejected. - Separate failure detection, election, state recovery, and traffic rerouting. Interviewers often probe the interval between detecting a failure and safely serving requests again. - State the partition policy and timeout trade-off explicitly. Be ready to explain quorum loss, lease assumptions, and why leadership does not guarantee exactly-once side effects. ## Common mistakes - Treating a missing heartbeat as proof that the old leader has stopped running. - Assuming a distributed lock or expired lease automatically prevents a paused owner from writing later. - Adding fencing tokens to requests without explaining which resource validates them and how a new generation becomes authoritative. - Promoting any available replica without checking whether it can preserve committed data. - Using one global leader for independent work that could use partition-level ownership or transactional work claiming. ## Interview questions where it comes up - [Design a control plane for a distributed database](https://sysround.com/questions/design-database-control-plane): Controller authority, fenced failover, and preventing conflicting lifecycle operations are central to a safe control plane. - [Design a distributed message log like Kafka](https://sysround.com/questions/design-kafka): Partition leader election must preserve committed records and ordering while rejecting stale leaders after failover. - [Design a distributed message queue like RabbitMQ](https://sysround.com/questions/design-message-queue): A leader-based replicated queue must safely transfer authority over durable queue state without losing acknowledged messages. - [Design a distributed job scheduler](https://sysround.com/questions/design-job-scheduler): A leader-per-shard scheduler needs safe dispatcher takeover, durable occurrence recovery, and protection against stale dispatchers. ## FAQ ### What is the difference between leader election and consensus? Leader election selects an authority; consensus lets nodes agree on decisions despite failures. Consensus protocols such as Raft include leader election, but electing a leader alone does not provide replicated state, durable commits, or safe recovery. ### Can a distributed lock be used for leader election? Yes, a lock or lease in a strongly consistent coordination service can select one active owner. However, a paused process can resume after losing its lease, so protected operations still need fencing or an equivalent authority check. A local check that the lease is valid is insufficient because the process can pause between that check and the operation. ### How does leader election prevent split-brain? A majority-based protocol prevents disjoint groups from independently electing leaders for the same term, but an old leader may still believe it has authority. Safe designs combine election with quorum-based commit rules or fencing so stale leaders cannot produce conflicting authoritative effects. During a partition, the minority side must stop the protected work rather than continue independently. ## Related concepts - [Consensus algorithms](https://sysround.com/concepts/consensus) - [Raft](https://sysround.com/concepts/raft) - [Split brain](https://sysround.com/concepts/split-brain) - [Distributed locks and fencing tokens](https://sysround.com/concepts/distributed-locks) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.