A lease is a lock with an expiration date. Instead of holding a resource until you explicitly release it, you hold it for a fixed time window and must renew before it expires. If you crash, get partitioned, or simply forget — the lease expires and someone else can take over. Leases are how distributed systems avoid the classic problem of zombie owners: nodes that think they still hold a lock but have been disconnected for minutes.

Leases are everywhere once you start looking. Kubernetes uses them for controller leader election — the active controller-manager renews a lease every 2 seconds; if it stops, a standby takes over within 15. DHCP hands out IP addresses on leases (typically 24 hours) so abandoned addresses get reclaimed. Chubby and etcd expose leases as a primitive: attach a TTL to a key, and it disappears if not refreshed. AWS S3 multipart uploads expire after a configurable window so half-completed uploads don't accumulate forever.

The mechanism solves three problems at once:

• Crash recovery without distributed consensus on death. You can't reliably detect that a node died — but you can detect that it stopped renewing.
• Bounded blast radius for stale work. A node that's been GC-paused for 30 seconds and wakes up holding a 10-second lease knows to stop touching the resource.
• Self-healing without manual intervention. No oncall page to "release the stuck lock."

The math that matters: pick three numbers.

• Lease duration (L) — how long an owner holds it. Long = fewer renewals, more downtime when an owner dies.
• Renewal interval (R) — usually L/3. Gives you two retries before expiry.
• Clock skew budget (S) — assume clocks drift. Owners should treat their lease as expiring at granted_at + L − S, not when the server says it expires.

Rule of thumb: If failover within 30 seconds is acceptable, use L=30s, R=10s, S=5s. The owner stops touching the resource at 25 seconds in; the cluster gives it up at 30. That 5-second gap prevents two nodes from briefly believing they both own it.

The trap to avoid: the lease holder's clock is not the source of truth. If you generate the lease locally and your VM gets paused for 60 seconds, you'll wake up and think you still own a 30-second lease. Always pair leases with fencing tokens — a monotonically increasing number stamped on every operation the lease authorizes. The storage system rejects operations carrying a token older than the latest it has seen, so a zombie owner can't corrupt data even if its clock lies.