Advanced14 min

Leader Election

Pick exactly one instance to hold a role — and make sure only one ever does.

By the end of this lesson, use quorum and fencing to elect a single leader safely despite partitions.

How deep?

How the pieces actually move.

Some jobs must be done by exactly one instance at a time: a scheduler, a primary database, a partition owner. Leader election is how a cluster agrees on that single instance — and, crucially, ensures a deposed leader can't keep acting after a new one is chosen.

First, the whole system

First, see the whole system. Then we’ll open it up.

Quorum elects, lease + fencing enforces

Candidates elect a leader by majority vote; the leader holds a time-bound lease and carries a fencing token so the resource rejects a stale ex-leader.

flowchart TB
  nodes[Candidate nodes] -->|majority vote| leader[Elected leader]
  leader -->|holds time-bound lease| work[Does the exclusive work]
  leader -->|fencing token increments| store[Resource rejects old tokens]

Two leaders (split brain)

Trigger: A partition or paused leader combined with election that lacks quorum or fencing.
Symptom: Two instances both act as leader and issue conflicting writes.
Blast radius: Data divergence across the resource the leader controls.
Mitigation: Quorum-based election, time-bound leases, fencing tokens, odd node counts.

Deep dive: Split Brain

How it connects

Why isn't a lease alone enough to prevent two leaders?

A paused old leader can resume believing its lease is valid; fencing tokens ensure the resource rejects its stale writes in favor of the new leader's higher token.