Leases & Fencing Tokens
Grant temporary authority without allowing a paused or partitioned former owner to corrupt shared state.
2–5 minute refresher
R + W > NN = 5 · R = 3 · W = 3
12345
Node 3 is the guaranteed overlap.
A lease suggests who owns authority; a fencing token lets the resource reject everyone older.
30second
refresher
refresher
A lease grants authority for a bounded interval. Because a holder may pause, lose connectivity, and resume after expiry, safe systems pair leases with monotonically increasing fencing tokens checked by the protected resource.
What problem does it solve?
Two workers can both believe they own a resource when one pauses past expiration or cannot observe renewal failure. Local clocks and process health cannot prove exclusivity.
How it works
- Acquire authority from a strongly consistent coordinator.
- Receive an increasing epoch or fencing token.
- Attach that token to every protected mutation.
- Have the resource reject stale tokens.
- Renew for liveness, but rely on fencing for safety.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Short lease | Fast failover | More false expiry |
| Long lease | Fewer renewals | Slower recovery |
| Fencing | Rejects stale owners | Every resource must participate |
What happens if?
A paused owner wakes up
Worker A pauses after acquiring lease 41. Worker B obtains lease 42 and begins work. A resumes and writes successfully unless the resource compares fencing tokens.
Where it appears
- Schedulers
- Metadata leaders
- Distributed locks
- Object-store writers
Senior interview modeWhy is a distributed lock alone insufficient?Show answer
The coordinator can grant a new lock, but it cannot erase the old holder's memory or stop its network requests. Safety requires the resource receiving mutations to distinguish new authority from stale authority.