Distributed Lock Service  ·  View 08 of 26  ·  3 · Structure

Integration Surface — Every Interface

Three inbound contracts, five outbound dependencies, and the one interface that should be used as little as possible.

Editable source SVG draw.io All views
Consumers Client library lockctl CLI Unfencable resource Prometheus Lock service Lock arbiter + Admin API proto · buf-checked Dependencies etcd clusters SPIRE Keycloak Kubernetes API OTel Collector Lock v1 gRPC Admin v1 gRPC ValidateToken scrape etcd v3 SVID OIDC CRD watch OTLP Integration Surface — Every Interface Application we own External / third party Security / platform Data store synchronous event / async ValidateToken is the Phase 2 fallback. Every call puts this service on a resource write path. v 1.0 · owner Platform Architecture · date 2026-09

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.