Distributed Lock Service · View 01 of 26 · 1 · Context and scope
Decisions
- The service decides who is entitled to act on a key and makes that entitlement checkable later. It never performs the guarded work and never touches the guarded data.
- Guarded resources sit outside the boundary but are drawn on the context view on purpose. Mutual exclusion is a property of their write path, and a context view that hides them implies the lock alone keeps writers apart.
- Unfenced legacy stores are drawn as a risk, not as a customer. The service still issues ordered grants to them, and the gap is registered rather than forgotten.
Assumptions
- A mid-size estate: a few hundred services, 300 namespaces, 2,000 client workloads and 40,000 sessions, all inside one organisation's data centres.
- SPIRE, Keycloak, Git with Argo CD and the observability stack already exist as shared platform services. The lock service consumes them and owns none of them.
- Kubernetes control-plane leader election keeps using Kubernetes Lease objects. A lock service that the cluster needs in order to start is a circular dependency.
Out of scope
- Distributed transactions, sagas and cross-key atomicity. A lock is not a transaction and is not sold as one.
- Rate limiting and idempotency for callers. Both are cheaper problems that are often mistaken for locking problems.
