The Runtime Theory

Leader Election with Fencing: Tokens That End Split-Brain

Watch nodes compete for the leadership lease, and see how a fencing token stops a stale leader from writing — the guarantee that makes failover safe.

The Runtime Theory Team09 stages

trace / request.md

NODES STARTCOMPETINGCANDIDATES RACEFOR THE LOCKONE NODEHOLDS THE LOCKLEADERSHIPHAS A LEASELEASE IS RENEWEDLEASE EXPIRESNEW LEADER GETSA HIGHER TOKENNEW LEADERTAKES OVEROLD LEADERIS FENCED

readyMultiple nodes start, all capable of leading. Exactly one should act as leader at a time — the election is really a distributed lock with a lease, stored in a coordination service.

Leader election solves "who is in charge"; fencing tokens solve "how do we know the old leader is really out." This diagram runs the full sequence: candidates contend for a lock, one wins with a lease, renews it, fails, and a successor takes over — then the original wakes up and tries to write. The fencing token is the detail that makes the story safe. When the successor acquires the lock, it receives a strictly greater token, and the shared resource checks every write's token against the current one.

Without fencing, failover is a guess. The old leader may simply have been partitioned or paused — it still believes it holds the lease, and its writes arrive after the new leader's, corrupting the shared state. With fencing, the resource itself enforces single-writer semantics: the stale leader's token is lower, so its writes are rejected. The stages are ordered by trust — lease expiry, token increment, then fencing — and the ordering is exactly what rules out split-brain.