Distributed Lock Service · View 16 of 26 · 5 · Runtime
Decisions
- Waiters for a key queue on the arbiter that owns the key's ring-hash slot, in arrival order. On release the arbiter attempts a grant for the head of the queue only, so one release causes one transaction, not forty.
- Queue order is declared best-effort. It survives an etcd leader change, because the queue is not in etcd, and it is lost when the owning arbiter restarts or the ring rebalances. Waiters then retry and order is re-established.
- Classes that need fairness across arbiter loss can opt into durable waiter keys under /q. Each waiter then costs two consensus writes, which is published on the class PR.
Bounds
- Every wait carries a deadline no longer than the class maximum. There is no indefinite wait.
- Queue depth past the class limit, 40 by default, is rejected with a distinct error. Forty waiters behind one key is a design problem to surface, not a queue to grow.
- A waiter whose session ends is removed from the queue immediately, not at its deadline.
Risks
- A hot key under sustained contention can starve a waiter across repeated arbiter restarts. The durable queue is the answer for classes where that matters.
