Multiplayer Collaborative Canvas  ·  View 14 of 23  ·  Runtime

Critical Flow — Reconnect and Catch-Up

Three paths out of the same message: replay, snapshot, or a branch the user is told about.

Editable source SVG draw.io All views
Local replica Admission Session router Session host Operation log Checkpoints 1. reattach at seq 4800 2. re-resolve capability 3. place document 4. attach, epoch 7 5. ops after 4800 6. 130 ops 7. catch-up, then live 8. 812 buffered ops 9. append merged 10. cold path: snapshot 11. past horizon: branch kept Critical Flow — Reconnect, Catch-Up and Offline Merge Message 10 is the alternative to replay when the client is further behind than the retained log; message 11 is the case beyond 30 days. v 1.0 · owner Platform Architecture · date 2026-10

Decisions

  • The cheapest sufficient path is chosen and reported: replay while the client's version is inside the retained log, snapshot plus tail otherwise. The client is told which happened, because the two have very different latencies (ADR-12).
  • Capability is re-resolved on reconnect (message 2). A client that was an editor when it dropped may come back a viewer, and the socket must not outlive the grant.
  • Buffered offline operations are appended as ordinary operations (message 9), under the live conflict rules — there is no privileged merge path.

What makes this survivable at scale

  • A host loss reattaches up to 20,000 clients at once. Admission control, jittered backoff and a cached snapshot are what stop the recovery becoming the outage (view 15).
  • Catch-up concurrency is capped per document, so one document's 200 editors cannot starve the log partition of another.

Assumptions

  • Log horizon 30 days past the checkpoint; client op buffer at least 10,000 operations.
  • Reattach p95 1.5 s including 30 s of missed operations.
◀  Critical Flow — Edit to Acknowledgement All views Session Handover  ▶
Solution Architecture v1.0 · Microsoft Azure · Platform Architecture · 2026-1014-reconnect-and-catch-up