Leader Election via Leases
TechniqueDistributed SystemsMidSeniorUpdated
A would-be leader acquires a time-bounded lease in a consensus store; it must renew before expiry or lose leadership. Bounds split-brain to one lease window.
When to Use Leader Election via Leases
You need at-most-one writer or coordinator and can tolerate a short unavailability gap on failover. Safer than ZK ephemeral nodes alone because clocks are bounded.
In Practice
Chubby (Google's lock service) pioneered this, Kubernetes controller-manager and kube-scheduler elect a leader via a Lease object in etcd, and CockroachDB range leases use it.
How Leader Election via Leases Comes Up in Interviews
Scenario
A Kubernetes controller must have exactly one active replica writing to the API at a time; the standby should take over within ~15s if the active dies.
kube-controller-manager uses a Lease object in etcd: holder renews every few seconds, others wait until expiry. Bounds split-brain to one lease duration.
Lease duration trades failover speed for risk of false take-over during a GC pause. Common defaults: 15s lease, 10s renew, 2s retry.