Multiplayer Collaborative Canvas  ·  View 16 of 23  ·  Runtime

Two Planes Under Load

Edits, presence and viewers through the same six stages — and the order in which things give.

Editable source SVG draw.io All views
Client Edge Session host Record Fan-out Peers Edit plane Op, rendered first Capability check Sequence + resolve Fenced append Direct socket push Apply at seq Presence plane Cursor at 20 Hz Rate limit Coalesce to 10 Hz Web PubSub group Render cursors Viewer plane Open by link Link scope Snapshot + tail Checkpoint read Viewer group Read-only render Under load Buffer locally 429 + retry hint Defer presence Never deferred Shed presence, then viewers Stale cursors Two Planes — Edits, Presence and What Gives Under Load The Record column is the one cell in the shedding row that cannot be degraded: an edit is acknowledged or refused, never queued in hope. v 1.0 · owner Platform Architecture · date 2026-10

Decisions

  • Presence and edits are separate channels. The cost of losing the ordering relationship between a cursor and the edit it precedes is accepted, because nothing in the product depends on it and the shedding independence is worth more (ADR-07).
  • Presence is coalesced server-side to 10 Hz whatever the client sends, so a client cannot buy itself more fan-out by sending faster.
  • Shedding order is declared: presence, then viewer broadcast, then non-essential telemetry. Edits and their acknowledgements are last, and are refused rather than deferred.

Why this is the cost page

  • Presence is the highest-volume and least valuable traffic in the platform — 1.5 million messages/second after coalescing, against 120,000 operations/second.
  • Its budget is capped at 25% of a multi-editor session's real-time message cost, and the coalescing rate is configurable without a deploy.

Assumptions

  • Clients emit cursors at up to 20 Hz; the server publishes at most 10 Hz per user.
  • A document may hold 200 editors and 1,000 viewers before further clients are admitted read-only.