Leader Election

Leader election is the process by which a group of distributed nodes picks exactly one node to act as the coordinator - the leader - for some task, such as writing to a partition, scheduling work, or making decisions on behalf of the group. When the current leader fails, the remaining nodes detect the failure and elect a new one.

Leader election requires two ingredients: failure detection (noticing the leader is gone) and leader selection (agreeing on a new one).

Failure detection

Nodes detect a failed leader through heartbeats: the leader sends periodic "I'm alive" messages, and if followers miss several consecutive heartbeats (a timeout), they assume the leader has crashed and trigger a new election. The timeout must be long enough to survive network jitter and short enough to recover quickly - a classic tension.

Election approaches

Consensus-based election (Raft / Paxos / ZAB): the most robust approach. Nodes run a consensus protocol to agree on a leader. In Raft, when a follower's election timer fires, it increments its term, votes for itself, and requests votes from peers. The first candidate to collect a majority becomes leader. This guarantees at most one leader per term and is the foundation of distributed consensus.

External coordination service: instead of building election into every service, delegate it to a proven system like ZooKeeper, etcd, or Consul. Nodes compete to create an ephemeral lock; the winner is the leader. When the leader's session expires (crash or disconnect), the lock is released and another node claims it. This is the pragmatic FAANG answer for most application-level leader election.

Bully algorithm: the node with the highest ID that is alive becomes leader. Simple but generates more election traffic and does not handle network partitions well.

Split-brain

The biggest danger is split-brain: a network partition isolates the old leader from the rest of the cluster, and both the old and the new leader believe they are in charge. Consensus protocols prevent this by requiring a majority quorum - a partitioned leader that cannot reach a majority steps down. Fencing tokens (monotonically increasing IDs attached to the leader's operations) let storage reject stale writes from an old leader that hasn't realized it has been replaced.

Fast failover (short heartbeat timeouts) detects failures quickly but triggers false elections during brief network blips, temporarily disrupting the system. Long timeouts are stable but delay recovery. Consensus-based election is correct under partitions but adds protocol complexity; external coordination is simpler to consume but adds an operational dependency on the coordination service.

• When your design has a "single responsible node," proactively say "and here is how we elect a new one if it fails."
• Default to "we use etcd/ZooKeeper for leader election" for application-level leadership - it is the pragmatic FAANG answer.
• Always mention split-brain and say "quorum-based election + fencing tokens prevent it."
• Tie election to distributed consensus if the interviewer wants depth.