Leader election for system design interviews

How it 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.

A 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 to say out loud

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 reach for it

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.

Where it comes up

Interview questions where leader election is part of a strong answer, and why.

Questions people ask

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.