The Runtime Theory
easyApplicationDSA#distributed-systems#leader-election#leases#coordination

Explain how leader election works and what a lease is

They want the two mechanisms that make 'one leader' safe: majority-based election, and a lease that time-bounds authority so a dead leader's claim expires.

The Runtime Theory Team2 min readasked at cockroachlabs · amazon · google · microsoft

This is a mechanism question: can you say exactly how a system guarantees one leader, and what happens when the leader stops talking. The two mechanisms are election and lease, and a strong answer keeps them separate.

Leader election picks the leader: in Raft, followers run randomized timers; the first to time out bumps its term, votes for itself, and asks every peer for a vote. Winning requires N/2+1 votes, and because majorities intersect, no two nodes can win the same term. In etcd or ZooKeeper the same idea appears as a lock: nodes race to create a named key; exactly one wins. Either way, the property is the same — at most one leader per term, decided by a quorum that can't split.

A lease is the second half, and it's what makes election safe against a dead or partitioned leader. A lease is authority with an expiration: the leader's position is valid only for a bounded time — etcd leases run 5–60 seconds by default, ZooKeeper sessions 30s — and the leader must renew it with heartbeats before it expires. The contract: followers hold the expiry time, the leader holds the grant time, and the lease is a duration computed with clock-drift margin baked in, e.g. grant 10s but treat 8s as the hard stop. Because expiry is enforced locally by the followers, a partitioned leader's claim simply runs out even though no one can reach it.

Walk through the failure: leader L holds a 10s lease, the network partitions it off. Followers stop hearing heartbeats; at the expiry moment L's authority is gone. A new leader L2 is elected — it doesn't need L's permission, the lease expired. Now L comes back, still believing it's leader; its lease is expired, so its commands reference a dead grant and are rejected. The critical rule: the old leader must never get away with writing after expiry — which is why leases are paired with fencing tokens, the storage-layer enforcement that rejects stale writers.

The tradeoff is a dial: short leases fail over fast but get broken by GC pauses and clock drift — a 200ms stop-the-world pause burns 20% of a 1s lease; long leases are stable but mean slow recovery when the leader actually dies. Real systems budget: lease duration must exceed the maximum expected pause plus clock skew, or you get two overlapping leaders and a split brain.

This answer walks

Follow-ups they'll push on

  1. 01What happens if the leader's lease expires while the leader process is still alive?
  2. 02How does a lease interact with a fencing token?
  3. 03Why 10 seconds and not 100 milliseconds?

More interviews in this topic

One dispatch a week

The trace behind each question, the tradeoff that explains it, and one technical dispatch per week — no noise.

One technical dispatch per week. No noise.