Distributed Lock Service · View 22 of 26 · 6 · Operations
Decisions
- Scale-out is always more clusters, never bigger ones. Adding members to a Raft group adds durability and read capacity and reduces write throughput.
- Rehoming a key range is fenced by an epoch advance on the destination above the source's epoch. Epochs are allocated from the coord cluster, so no two clusters ever share one.
- No stretched quorum by default. A global lock is deferred until a genuinely global resource exists, and then priced at p99 150 ms per acquisition before anyone commits to it.
Triggers, not dates
- Split coord from entity when leader-election locks see a latency incident caused by entity churn, or at Phase 2, whichever comes first.
- Add an entity shard when steady writes exceed 60% of the benchmarked ceiling for a week, or live state passes 4 GB.
What does not change
- The gRPC contract, the token encoding, the class schema and the fence rule at the resource. Everything a service owner built against in the MVP still works at Phase 3.
