Distributed Lock Service  ·  View 17 of 26  ·  5 · Runtime

What Each Lock Class Guarantees When Things Break

The same failures, three declared postures, and where each posture stops making promises.

Editable source SVG draw.io All views
Normal Holder pauses Renewal fails Quorum lost After recovery Correctness · fenced Grant + token Stale write rejected Fence at local deadline No grants · self-fence Epoch advance first Correctness · advisory Grant + token Double write possible Fence at local deadline No grants · self-fence Epoch advance first Efficiency Grant + token Duplicate work only Fence at local deadline Open if declared Reconcile unprotected What Each Lock Class Guarantees When Things Break Postures are declared on the class and reviewed by the resource owner. Nothing here is a runtime default. v 1.0 · owner Platform Architecture · date 2026-09

Decisions

  • Every class declares enforcement (fenced or advisory) and quorum-loss posture (closed or open). Neither has a default; the class schema rejects a file that omits them.
  • Correctness classes are always fail-closed. Fail-open exists only for efficiency classes, and every grant issued while open carries token zero and an unprotected flag in the audit record.
  • The platform claims mutual exclusion only in the top lane. For the other two it claims ordered grants and nothing more, and the documentation says exactly that.

How fail-open works without the log

  • When the quorum is unreachable, an arbiter may grant an efficiency-class key from its own memory, spooled to a local write-ahead file. The spool ships to the audit store on recovery as the reconciliation list.
  • Phase 3 only. The MVP is fail-closed for every class.

Assumptions

  • Most classes in a real estate turn out to be efficiency classes: cache warmers, report generators, deduplicating schedulers. The posture is worth declaring precisely because it is usually the cheap one.