Distributed Lock Service · View 14 of 26 · 5 · Runtime
Decisions
- The grant is one etcd transaction: compare the epoch key and compare the lock key absent, then put the holder key on the caller's session lease. Epoch check, exclusion check and grant commit as one Raft entry.
- The token is (epoch, revision of that transaction). It is known the moment the commit returns and nothing else has to be written to create it.
- Release is a transaction that deletes the key only if it is still attached to the caller's lease. A late release from a holder that already lost the lock deletes nothing.
Latency budget, p99 40 ms
- Envoy and arbiter: under 3 ms including mTLS on a warm connection.
- Raft commit: leader append, two follower appends and fsyncs across halls, majority ack. Sub-millisecond network, 1 to 5 ms NVMe fsync at the tail.
- The rest is queueing at 30,000 writes a second of burst. That is where p99 is actually lost, and why the benchmark must be run at burst, not at steady state.
What the resource must do
- Store the highest token it has accepted per guarded record and reject any write carrying a token less than or equal to it, atomically with the write. A check followed by a separate write is not a fence.
