Edge and reliability / Advanced / 7 min
Distributed locks, leases and fencing tokens
A frozen worker wakes after its lease ran out and overwrites someone else. Fencing tokens make storage refuse it.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- A distributed lock lets one of many machines do something at a time, usually as a lease that expires after a set time.
- Why it matters
- Two workers running the same job or writing the same record at once can corrupt data or charge twice.
- The trade-off
- A lease that is too short expires under a slow holder; too long and a crashed holder blocks everyone, so neither is safe on its own.
- Say it in an interview
- "I take a lease lock with a fencing token, and the storage rejects writes with a token older than the newest it has seen."
Check yourself
Why does a distributed lock usually have a lease (an expiry time)?
Answer: So a crashed holder cannot keep the lock forever. Without expiry, a holder that crashes never releases the lock and everyone waits forever.
A worker pauses for 5 s while holding a 2 s lease. What can go wrong?
Answer: The lease expires, another worker takes the lock, and both write. The paused worker does not know its lease ended. When it wakes it writes as if it still held the lock.
How does a fencing token stop the late write?
Answer: Storage refuses any write whose token is lower than one it has already accepted. Each grant gets a higher token. The new holder writes with a higher token first, so the old one is refused.