How does leader election work in distributed systems?
Leader election is the process by which a group of distributed nodes agrees that exactly one node — the leader — is responsible for coordinating writes, holding a lock, or running a singleton process. Without a reliable election mechanism, you get split-brain: two nodes both believe they are leader, causing conflicting writes and data corruption.
The core challenge is that any election algorithm must handle the impossibility result (FLP): in an asynchronous network with even one faulty process, you cannot guarantee both safety (one leader at a time) and liveness (an election always completes). Practical systems relax the asynchrony assumption using timeouts.
**Raft** is the most widely understood algorithm. Nodes start as followers. If a follower receives no heartbeat from a leader within an election timeout (150–300ms typically), it transitions to candidate, increments its term, and sends `RequestVote` RPCs to all peers. A node votes for at most one candidate per term. The candidate that collects a majority of votes becomes leader for that term, immediately sending heartbeats to suppress new elections. Raft guarantees that only a node with the most up-to-date log can win — voters reject candidates whose log is behind theirs.
**ZooKeeper (ZAB protocol)** uses a similar approach: ephemeral sequential znodes. Each node creates a znode under `/election/`; the node with the lowest sequence number is the leader. All others watch the znode immediately preceding theirs. When the leader's ephemeral node disappears (session timeout), the next-lowest znode holder becomes leader. This avoids the thundering herd of all followers watching a single node.
**etcd** exposes a lease-based leader election API. A candidate writes a key with a TTL-backed lease. If it wins the compare-and-swap (key did not previously exist), it is leader. The leader must renew the lease periodically; if it crashes, the lease expires and another candidate wins.
**Fencing tokens** are critical for safety. Even after a leader loses its election, it may still believe it is leader due to a network partition (the "stale leader" problem). Every operation should include a monotonically increasing fencing token issued by the election system; the storage layer rejects requests with a lower token than it has seen. This prevents a stale leader from corrupting state.
In practice: use etcd or ZooKeeper for production leader election rather than implementing your own. Rolling your own timing-based election is a common source of split-brain bugs.
Explains the split-brain risk, describes Raft or ZooKeeper election at a conceptual level, and mentions lease/heartbeat-based failure detection.
Covers Raft voting mechanics (terms, majority, log freshness check), ZooKeeper ephemeral znodes, fencing tokens to handle stale leaders, and the FLP impossibility result as motivation for timeout-based heuristics.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment