Distributed Lock Service · View 08 of 26 · 3 · Structure
Decisions
- The protocol is gRPC with protobuf, versioned as lock.v1 and admin.v1. buf breaking-change checks run on every pull request, so a field cannot be renumbered by accident.
- Acquire, Renew-session, Release, Watch and Inspect are the whole client surface. A small API is what lets it outlive the implementation behind it.
- ValidateToken exists for resources that cannot store a high-water mark. It is rate-limited separately and reported per namespace, because every call puts the lock service on someone's write path.
Dependencies, and what happens without them
- SPIRE down: existing SVIDs remain valid for their one-hour life. New workloads cannot connect; held locks are unaffected.
- Kubernetes API down: arbiters keep their last loaded classes and keep serving. Class changes wait.
- Keycloak down: force-release is unavailable. Grants and releases are unaffected. That asymmetry is intended.
Omitted
- Admin API to Arbiter internal calls and the ClickHouse read path for reports. Neither crosses the service boundary.