Sweaty Imposter

Leases + TTL

TechniqueCoordinationSeniorStaffUpdated
Grant time-bounded exclusive ownership. Holder must renew before expiry; if it dies, the lease auto-releases.

When to Use Leases + TTL

Leader election, distributed locks, work assignment. Avoids 'zombie owner' problems where a crashed node holds a lock forever.

In Practice

Kubernetes leader election (controllers all try to grab a lease in a ConfigMap, renew every few seconds). Chubby and etcd are built around lease primitives.

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.

Where It Comes Up