Stackbook Logo
coordinationestablished · low operational burden

Lease-Based Locks

Also known as: leases, time-bounded-locks, ttl-locks

Intent

Grant exclusive access for a bounded time so that a crashed holder cannot block others forever.

Problem

A plain lock held by a crashed or partitioned client is never released, blocking everyone. Detecting a dead holder perfectly is impossible in asynchronous networks. The system needs automatic recovery of abandoned locks.

Forces

  • •Holders can crash without releasing
  • •Failure detection is unreliable
  • •Clock drift affects expiry decisions
  • •Short leases churn while long leases delay recovery

Solution

Overview

A lease is a lock with an expiry. The holder owns the resource only while the lease is valid and must keep renewing it. If it dies or is partitioned away, the lease lapses and the lock becomes available again. Google Chubby, etcd and Kubernetes leader election use leases.

How it works

t=0   acquire(lock, ttl=15s)   -> lease granted, id=L1
t=5   renew(L1)                -> expires at t=20
t=10  holder crashes
t=20  lease expires
t=21  other client acquires    -> lease L2

A typical implementation renews at one third of the TTL, so two missed heartbeats are tolerated. In a database-backed form, a row holds owner and expiry, and acquire is a conditional update: set owner when expiry is in the past or owner is self. The holder should stop work if it has not renewed within the TTL minus a safety margin.

Pitfalls

  • Pauses from GC, VM migration or CPU starvation can outlast the TTL; the holder wakes believing it still owns the lock. Add fencing tokens to the protected resource.
  • Relying on local time comparisons across machines invites clock skew bugs; prefer monotonic clocks on the holder and server-side expiry.
  • A TTL too short causes constant failover; too long delays recovery.
  • Renewals must go to a replicated store; a single-node Redis loses leases on failure.
  • Release explicitly on graceful shutdown to speed handoff.

Key takeaways

  • Leases convert unbounded waiting into bounded unavailability.
  • Renew at about one third of TTL and stop work when renewal fails.
  • Pair leases with fencing tokens whenever correctness matters.

✓ When to Use

  • •Leader election and master ownership
  • •Work claims such as job or partition ownership
  • •Cache and read leases that bound staleness

✗ When Not to Use

  • •Critical sections where a pause beyond the TTL would corrupt data and no fencing exists
  • •Very short operations better served by compare-and-set
  • •Environments with unbounded clock skew

Pros

  • +Automatic recovery from crashed holders
  • +Simple mental model
  • +Supported by etcd, ZooKeeper, Consul and DynamoDB

Cons

  • −Safety depends on timing assumptions
  • −Renewal traffic and heartbeat tuning
  • −Stale holders can act after expiry

Cost Profile

Infrastructure

Lock store such as etcd or a database table

Operational

Low: tune TTL and renewals

Cognitive

Medium: timing reasoning

Failure Modes

  • Process pause longer than TTL leads to two holders

  • Renewal failure during transient network blip drops leadership needlessly

  • Clock skew shortens or extends effective lease

Real-World Examples

Alternatives

    Related Patterns

    • distributed-lock
    • leader-election
    • fencing-tokens

    Competency Domains

    distribution communicationreliability ops