Leader Election
Select one current coordinator and prevent stale leaders from continuing to act.
2–5 minute refresher
term 8Leader1 2 3 4
node 1Follower1 2 3 4
node 2Follower1 2 3 4
node 3Follower1 2 3 4
node 4Follower1 2 3 4
Elect authority → attach an epoch → fence every side effect
30second
refresher
refresher
Leader election lets a group choose one node to coordinate writes, scheduling, or ownership. A safe design also proves freshness with a term, epoch, or fencing token so an isolated former leader cannot keep acting.
What problem does it solve?
Some operations need a single authority to serialize decisions or avoid duplicate work. Static ownership fails when the owner crashes, while informal failover risks two active leaders.
How it works
- Followers monitor heartbeats or a lease deadline.
- A candidate advances the term and asks a quorum for votes.
- Voters grant at most one vote per term under the protocol rules.
- The winner publishes its term with every command.
- Resources accept only commands with a term at least as new as the last one observed.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Short timeout | Fast failover | False elections during delay |
| Long timeout | Stable leadership | Longer recovery |
| Lease leader | Fast local decisions | Clock and pause assumptions |
What happens if?
The old leader is paused, not dead
After a long process pause it resumes with stale authority. Without fencing it can overwrite the new leader's work. A monotonically increasing token lets storage reject that command.
Where it appears
- Raft
- ZooKeeper recipes
- etcd elections
- Kubernetes controllers
Senior interview modeWhy is a distributed lock without a fencing token unsafe?Show answer
The holder may pause past expiry and later resume. Another client can acquire the lock meanwhile, so both can act unless the protected resource rejects the stale holder's lower token.