Distributed Lock Service · View 11 of 26 · 4 · Data
Decisions
- The token is not a stored counter. It is the epoch in the top 16 bits and the etcd revision of the granting transaction in the low 48, so it is minted by the commit itself and needs no extra key per lock.
- A session is an etcd lease owned by one SPIFFE identity at one TTL. Holds attach to it, so renewing one session renews every hold on it in a single keepalive.
- Force-release has its own record joined to the audit event by revision. The reason and both approvers survive long after the lock key is gone.
Why revision and not a per-key counter
- A per-key counter must be kept forever or it restarts at one. Four million keys a day would make the counter table the largest thing in the store.
- etcd revisions are cluster-wide, strictly increasing and never reused, which is stronger than per-key monotonicity. Gaps are expected and harmless.
Headroom
- 48 bits of revision is 2.8 × 10^14. At a sustained 30,000 commits a second that lasts about 297 years per epoch. Epochs are kept below 2^15 so the token stays positive in a signed 64-bit column, which still allows 32,767 restores or rehomes.