The Runtime Theory

Leader Lease Renewal: TTL, Heartbeats, Expiry, and Fencing the Stale Leader

Follow leader leases through acquisition, periodic renewal, missed renewals, expiry, takeover by a new leader, and fencing via stale tokens.

The Runtime Theory Team08 stages

trace / request.md

LEASE ACQUIREDLEADERSHIPASSUMEDRENEWAL KEEPSIT ALIVEFOLLOWERSRESET TIMERSRENEWALS STOPLEASE EXPIRESNEW LEADERTAKES OVERSTALE LEADERFENCED

readyA winning candidate writes its lease to the consensus store: a key mapping leader identity to a token with a TTL — typically 10 seconds. The cluster now has a leader with a deadline.

A leader lease is a liveness bet with a deadline. The leader's authority is stored as a key with a TTL, and staying in charge is a repeated action: renew before the TTL lapses, every time, indefinitely. The renewal cadence — renew at half the TTL, say — is what makes the lease meaningful: it guarantees that any observable gap in leadership is at most one TTL long.

Expiry is the mechanism that turns a dead leader into a former leader without anyone having to prove the death. The followers' election timers are keyed to the lease record, so when renewals stop, the election starts by itself. The fence is the backstop: a revived leader with an expired lease holds a token the cluster has already superseded, so its writes are rejected by validation, not by debate. The ordering — renew, expire, elect, fence — is the difference between a system that splits under partition and one that converges: the lease bounds the uncertainty, and the token makes the verdict enforceable.