Distributed lock service with fencing
Leases, heartbeats and fencing tokens over a consistent core — including the exact scenario where a GC-paused client gets fenced instead of corrupting data.
What this design does
A distributed lock without fencing tokens is a false sense of safety: a client can hold the lock, pause for a GC or network blip, lose the lease, and keep writing. This diagram shows the whole defense — leases that expire, heartbeats that renew, a monotonic fencing token minted per acquisition, and the storage layer rejecting the stale token. It's also the honest version of the Redlock debate.
The patterns it composes
- Lock with lease — ownership expires unless renewed — crashed holders release by silence
- Fencing token — monotonic token per acquisition; downstream rejects anything older
- Heartbeat — renewal doubles as liveness detection
- Consistent core — the lock table lives on a small Raft group, not a cache
- Generation clock — epochs make 'who owned it when' unambiguous during handover
Import it, attach your own numbers, and verify the design against failures — or read the engineering notes.