Multiplayer Collaborative Canvas  ·  View 15 of 23  ·  Runtime

Session Handover

How a document loses its authority and gets it back — and why the fence is at the store.

Editable source SVG draw.io All views
Steady state Session host A epoch 7, owner Lease 15 s TTL, renewed Loss Node lost no drain Lease expires Claim Session router Epoch 8 issued monotonic Fence Operation log rejects epoch 7 Rehydrate Session host B checkpoint + tail Checkpoints Reattach Admission control jittered backoff Clients unacked ops resent state: reconnecting Session Handover — Losing the Authority and Getting It Back Application we own Data store Risk / gap Decision point Interface / broker External / third party failure / alternate A zombie host A that wakes up still believing it owns the document writes at epoch 7 and is rejected: the fence is at the log, not in the router. v 1.0 · owner Platform Architecture · date 2026-10

The decision this view exists for

  • Ownership is a lease with a monotonic epoch, and the fence is enforced by the log's conditional write — not by the router, not by orchestration. A host that wakes up still believing it owns the document writes at the old epoch and is rejected (ADR-03).
  • That makes a brief double-ownership harmless rather than catastrophic, which is what allows a 15 s lease instead of a consensus round on every operation.
  • Clients resend unacknowledged operations after reattaching. Because operations are idempotent on (document, client op id), a resend after a handover is safe.

Numbers

  • Lease TTL 15 s, renewed every 5 s; re-host RTO p95 10 s including client reattach.
  • Loss bounded to operations that were never acknowledged — RPO 0 for everything the client was told was safe.
  • All stated assumptions.

Risks

  • A lease store outage stops handover. The platform's answer is to fail closed on saving (documents go read-only) rather than permit two authorities, because a split document cannot be repaired after the fact.