CONCEPT Cited by 1 source

Reachability-based subscription

Reachability-based subscription is a server-side real-time collaboration pattern in which a session's subscription to document edits is defined as the transitive closure of the node the session loaded, under a dependency graph of the document. Edits to nodes outside that closure are filtered at the server and never sent to the session. Changes to dependency edges implicitly grow or shrink the closure for affected sessions, and those sessions receive the newly reachable nodes as part of edit delivery.

Contrasts with the naive "everyone subscribed to the file gets every edit on the file" model and with coarser per-page or per-folder subscriptions — both of which send data the session will never look at and inflate client memory + network usage.

(Primary source: sources/2024-05-22-figma-dynamic-page-loading — Figma Multiplayer's subscription model.)

Shape

Given a document with:

• Nodes N.
• A (bidirectional) dependency graph G = (N, E) where E encodes both read deps (what a node's rendering/editing depends on) and write deps (what a node's edits can derivedly affect). (concepts/write-dependency-graph)

A session S that has loaded starting node P has:

S.subscription_set = closure(P, E)
                   = { n ∈ N : n is reachable from P under read ∪ write deps }

The server's invariants:

1. Load-time shipping. On connect, ship S.subscription_set to the client.
2. Edit filtering. For an edit to node n, ship it to S iff n ∈ S.subscription_set.
3. Edge-mutation response. When a dependency edge is mutated (e.g. a node's foreign key is changed to point at a different dependency), recompute S.subscription_set for every affected session. Ship newly-reachable nodes.

Worked example (from Figma's post)

A user has loaded only page 1 of a Figma file. A collaborator:

1. Edits the fill of a rectangle on page 5. That rectangle is not reachable from page 1 → the edit is not shipped to the first user.
2. Swaps an instance on page 1 to a different backing component. The old component's subtree may become unreachable (if nothing else on page 1 references it); the new component's subtree becomes reachable. Multiplayer must recompute the first user's subscription set and **ship the new component + its descendants
3. their dependencies** even though the first user touched none of those nodes — the act of mutating the dep edge made them reachable.

Why it beats page-level subscription

Page boundaries are a natural unit for a user mental model, but the actual dependency graph crosses them:

• An instance on page 1 referencing a component on page 5 — the component must be loaded even though the user is on page 1.
• Cross-page write deps (Figma's post cites a "complex, cross-page, recursive write dependency involving frame constraints and instances") — an edit on one page can legitimately affect nodes on another.

Reachability is the only granularity that captures these correctly while still shrinking from "ship the whole file" to "ship only what this session actually needs."

Cost surface

• Graph maintenance — every feature that adds a new dependency type must add its edge to the graph, or reachability computation is incomplete. This is why patterns/shadow-validation-dependency-graph is the pre-condition for flipping this live.
• Recomputation on edge mutation — potentially expensive if a single edge swap fans out subscription updates across many sessions. Figma doesn't publish numbers on this.
• Server-side bookkeeping — per-session subscription state, plus the dependency graph itself, live in server RAM.

When it fits

• Real-time collaborative editing where sessions realistically only look at a small fraction of a document at a time (Figma files, long docs, large sheets, code repos).
• Editable datasets with derivation rules where silent divergence between derived and source state is a correctness issue (auto layout, spreadsheet formula propagation, component systems).

When it doesn't

• Read-only consumers — read-dep-only subscription is enough and cheaper. Figma's viewers/prototypes lived here for years.
• Documents with flat, mostly-independent structure — if most edits reach most of the document, the subset benefit disappears and the graph cost isn't justified.

Related

• concepts/write-dependency-graph — the graph this subscription is built on.
• systems/figma-multiplayer-querygraph — the instantiation at Figma.
• patterns/asset-preload-prediction — an analogous "only ship what's likely needed" subset-trimming move on the SSR tier.
• concepts/hot-key / patterns/shard-replication-for-hot-keys — what you reach for if one node ends up in a very large number of reachability sets (the hot-shared component).

Seen in

• sources/2024-05-22-figma-dynamic-page-loading — canonical real-time-collaboration example: Multiplayer computes each session's subscribed subset as the transitive closure of the initial page over read+write deps, ships edits iff the edited node is reachable, and expands subscriptions when dep edges mutate.