What it is
Given a cluster of N nodes, elect one leader that all others recognise as the coordinator. Every reliable primary-replica system (Postgres HA, MongoDB, Elasticsearch), every scheduler that must not double-run jobs, every stream processor with a coordinator relies on it. Get this wrong and you have two leaders (split brain) writing conflicting decisions.
The interview shows up whenever a design has 'one thing must be authoritative at a time' — job schedulers, replica sets, distributed transactions. Interviewers score on knowing that ad-hoc 'the oldest node wins' schemes fail under partitions, and that this is a solved problem with named algorithms.
For anything that must have exactly one owner, I'd use Raft leader election through etcd or Zookeeper — the algorithm is battle-tested, and I'd never hand-roll this at a small scale.
The variants and when to pick each
Raft — the modern default
Nodes vote in bounded terms. When a follower doesn't hear from a leader within a randomised election timeout, it becomes a candidate, increments term, and requests votes. Majority of nodes agreeing installs it as leader for that term. Every log entry the leader writes is committed only after majority ack; a partitioned old leader can accept writes but can't commit, so its data is safely discarded on rejoin.
Raft is what powers etcd, Consul, CockroachDB, TiDB, Kafka's KRaft. If you're building a coordinated system today, this is the answer unless you have a very specific reason.
Zookeeper ephemeral znodes — the classic
Every candidate creates an ephemeral sequential znode under /election. Whoever holds the lowest sequence number is the leader; others watch the znode immediately before theirs. When a leader dies, its ephemeral znode disappears, the watcher gets notified, checks if it's now lowest, and takes over. Chubby (Google), Kafka pre-KRaft, HBase master election all used this shape.
The clever bit: no thundering herd on failover. Only the next-in-line reacts; everyone else keeps waiting. Beautiful engineering.
Lease-based election with fencing
Candidates race to acquire a time-bounded lease from a strongly-consistent store. Winner holds it for the lease duration, must renew before expiry, and includes a fencing token on every write to whatever the leader controls. If the leader pauses past its lease, someone else takes over with a higher token — the paused leader's late writes get rejected downstream.
This is the pattern for 'one worker at a time' jobs, distributed cron, single-writer patterns over external resources. It's leader election through a lock service, and fencing is the correctness backbone.
Static leader (no election) — sometimes the right call
For small systems or during bootstrap, hardcoding a leader is fine. Every service says 'the leader is node-1'; if it dies, the system pages a human. Zero complexity, obvious failure mode, easy to reason about.
Do this when the cost of an outage exceeds the cost of election complexity — and be honest with yourself about when that's actually true.
Numbers worth memorising
| Raft election timeout | 150-300 ms randomised (typical) |
| Failover time | election timeout + heartbeat + application handoff = ~1-5 s |
| Quorum size for 5-node Raft | 3 (tolerates 2 failures) |
| Lease TTL for a job-lock scheme | 30-60 s with renewal at 1/3 of TTL |
| Fencing token size | monotonic 64-bit (Zookeeper zxid or Raft term:index) |
Where the interviewer pushes
First push: 'why can't the oldest node just be the leader?' Because in a network partition, two nodes may each think they're the oldest still alive — split brain. Any algorithm without majority voting can produce two leaders under partition, and two writers eventually corrupt state. Majority-based election is the only design that survives partitions.
Second push: 'what does the client do during a failover?' Retry with backoff. Clients should tolerate a few-second window where writes fail with 'no leader'. If a client caches the leader identity, it must have a way to refresh — usually the service discovery layer (Consul, etcd itself, or an SDK that walks the cluster) does this automatically.