Distributed Lock Service · View 04 of 26 · 2 · People and journeys
The trough, and the answer to it
- The low point is fencing the store. A legacy store with no conditional write cannot check a token, and the owner discovers this after they have already committed to using a lock.
- The platform's answer is a time-boxed advisory waiver: the class is created, marked advisory, given a named risk owner and an expiry date, and appears on the risk register until it is fenced or the waiver is renewed on the record.
Decisions it forces
- The first phase asks whether the store already has compare-and-set. If it does, the conditional write is the protection and the lock is often unnecessary. The cheapest lock is the one not taken.
- The LockClass pull request prints the renewal cost of the chosen TTL. Shortening a TTL for faster failover is a cost decision and the owner sees the number before merge.
- Go-live requires a staged pause test: the kit freezes a holder with SIGSTOP past its TTL and asserts the resource rejects its resumed write. A class cannot be marked fenced on assertion alone.
Assumptions
- Onboarding a fenced class takes a team two to four days, most of it in the store's write path, not in the lock client.
