Leases + TTL
When to Use Leases + TTL
In Practice
How Leases + TTL Comes Up in Interviews
Scenario
Kubernetes controllers all race to become the leader by writing to a single ConfigMap, and the winner renews its claim every few seconds. If the leader crashes, ownership expires automatically and another controller takes over. What's the underlying primitive?
Leases grant time-bounded exclusive ownership with auto-release on expiry, exactly the 'zombie-safe distributed lock' pattern. Heartbeats are a building block but the renewal-or-expire semantic is the lease.
Leases are time-bounded exclusive ownership with auto-release on expiry, the 'zombie-safe distributed lock' that fixes the classic problem of a crashed lock holder permanently blocking everyone else. Kubernetes controllers race to write to a single ConfigMap or Lease object, the winner renews every few seconds, and if the holder dies the lease expires automatically and another node wins. Chubby (Google), etcd, ZooKeeper, and Consul are all built around lease primitives at their core. The subtle correctness story is fencing tokens: the lease holder must include its lease epoch in every write to the underlying resource, so a partitioned-but-still-thinking-it's-leader node can't corrupt state after the real leader takes over.