TL;DR: Use one room-scoped channel for ephemeral cursor updates when every authorized participant sees the same data and a dropped intermediate position is harmless. Split traffic by device only when authorization, delivery policy, or failure isolation genuinely differs per device. A channel topology cannot manufacture exactly-once delivery; sequence numbers, expiry, idempotent state application, and bounded queues do that work. For a marketplace editor, the practical default is a shared cursor stream plus a separate durable path for document mutations, with device-scoped control streams introduced only at a measured boundary.
That answer is less tidy than “one channel scales better” or “more channels isolate failures,” because channel count is not the governing constraint. The governing constraint is what a receiver may safely miss, repeat, reorder, or observe. Cursors are replaceable state. A listing-description edit is not. Putting both into the same delivery contract is the first mistake, long before transport selection becomes interesting.
Should all devices use one channel or a channel per device?
A collaborative marketplace editor might show a seller, a copy editor, and a reviewer working on the same listing. Each person can have a laptop and a phone connected, yet a cursor update still represents only a transient claim: “actor A was near this position at sequence S.” If S+1 arrives, retaining S has no value. If S arrives after S+1, applying it makes the interface less truthful.
That leads to four requirements. A cursor event needs an actor identity distinct from a connection identity; a monotonically increasing sequence within the actor session; a room or document authorization boundary; and an expiry rule. Reconnection creates a new session epoch, because a counter restarted at zero must not make an old packet look current. None of these rules depends on whether all devices share one logical channel.
Document operations need a different contract. They normally require an authoritative ordering or a conflict-resolution protocol, durable recovery, and an acknowledgment model. Do not infer those properties from WebRTC connectivity. The WebRTC specification defines data channels and exposes ordered delivery plus retransmission controls, but application meaning remains the application's responsibility.
Loss is acceptable here. Ambiguity is not.
The receiver can therefore keep only the latest accepted cursor state for each actor and session. This Python model makes the discard rule explicit without pretending that a transport callback is a durable commit:
from dataclasses import dataclass
@dataclass(frozen=True)
class CursorUpdate:
room_id: str
actor_id: str
session_id: str
sequence: int
x: float
y: float
class CursorProjection:
def __init__(self) -> None:
self._latest: dict[tuple[str, str], CursorUpdate] = {}
def apply(self, update: CursorUpdate) -> bool:
key = (update.actor_id, update.session_id)
previous = self._latest.get(key)
if previous is not None and update.sequence <= previous.sequence:
return False
self._latest[key] = update
return True
The boolean is useful for metrics: duplicates and stale arrivals should be observable even though they are harmless to the projection. Room membership must be checked before this method is reached; accepting a well-formed packet from an unauthorized actor is still a security failure.
Shared and device-scoped designs fail differently
A shared room stream minimizes subscription state and matches the audience for public cursor positions. The sender publishes once to a room-level fan-out path, and each connected device filters its own echo if necessary. Operations stay legible: room membership, queue depth, stale-event rate, and fan-out delay describe most of the system.
Its failure domain is wider. A slow receiver can consume buffer space intended for peers if the relay does not maintain bounded per-connection queues. A noisy actor can also dominate the room unless ingress is rate-limited by actor or session. Head-of-line effects become especially awkward when cursor events share an ordered path with control messages: an old cursor is expendable, while a permission revocation is not.
Consider a failure drill, not a benchmark: one seller has the same listing open on a laptop and phone, while a reviewer is connected on a third device. The phone stops reading without closing its connection. Under a shared room design, the relay should continue replacing that phone's queued cursor state rather than allowing its backlog to retain every coordinate, and the laptop and reviewer should keep receiving current state through their own bounded connection queues. Under a per-device design, the stalled destination is explicit, but routing still needs to recognize and evict it; merely assigning a separate channel does not cap memory. Now reconnect the phone with a new session while packets from its old session remain in flight, then revoke the reviewer's access. The expected outcomes are concrete: the new session does not inherit the old sequence space, late old-session coordinates cannot move the new cursor, and revocation travels on a non-replaceable control lane. This drill exposes the operational difference without claiming a universal connection count or latency threshold.
A device-scoped design creates an independent logical destination for every connected device. That can express per-device authorization and different delivery policy cleanly. It can also confine backpressure, since a stalled phone does not require the laptop's queue to grow. The price is multiplicative operational state: subscriptions, routing entries, authorization checks, reconnect churn, and cardinality in telemetry now follow connections rather than rooms.
Neither layout removes fan-out. One performs it behind a shared subject; the other makes each destination explicit. The work still includes identifying recipients, applying authorization, bounding memory, and deciding what to drop.
| Decision surface | Shared room channel | Device-scoped channels |
|---|---|---|
| Audience | Best fit when authorized devices receive equivalent cursor state | Best fit when visibility or policy differs by device |
| Backpressure | Requires a bounded queue per connection behind the shared stream | Naturally exposes each destination, but creates more queue state |
| Reconnect | Restores room membership and starts a new session epoch | Must also recreate device routing and retire the old destination |
| Observability | Lower-cardinality room and actor dimensions | Fine isolation, with potentially expensive device-level dimensions |
| Failure mode | One hot room can stress shared routing and buffers | Subscription churn and orphaned destinations can dominate control work |
| Delivery policy | Easy when all cursor events are replaceable | Useful when some devices require a distinct policy |
The table does not produce a universal winner. It identifies the boundary worth testing.
Delivery guarantees belong above channel topology
“Exactly once” is a dangerous label for cursor fan-out because it collapses several separate events: acceptance by an ingress process, forwarding by a relay, arrival at a connection, and application by the UI. A reconnect can happen between any two of them. Even if one layer suppresses duplicates, the end-to-end effect still requires an application key and an idempotent receiver.
For cursor state, at-most-once delivery with replacement is often the honest contract: keep the newest position, tolerate gaps, and never wait for an obsolete update. WebRTC data channels expose ordered delivery as well as limited-retransmission configuration. Those controls let an application choose transport behavior, but they do not define actor identity, expiry, authorization, or how a reconnection changes sequence scope.
Control events deserve another lane. Membership changes, role changes, and session closure should not be discarded under the cursor policy. Likewise, durable document edits should travel through the editing protocol and storage path that can reconstruct accepted state after a process loss. A single physical connection may carry these logical lanes, but their queues and acceptance rules should remain separate.
This is where a storage architect's skepticism is useful: if the team cannot name the record that proves an edit was accepted, the system does not have a durability guarantee. A delivery callback is not that record. Conversely, persisting every cursor coordinate converts transient presence into write amplification and retention risk without improving the document's recoverability.
A small routing function can keep those policies visible:
from enum import Enum
class Lane(Enum):
CURSOR = "cursor"
CONTROL = "control"
DOCUMENT = "document"
def delivery_policy(lane: Lane) -> dict[str, object]:
if lane is Lane.CURSOR:
return {"ordered": False, "replaceable": True, "durable": False}
if lane is Lane.CONTROL:
return {"ordered": True, "replaceable": False, "durable": False}
return {"ordered": True, "replaceable": False, "durable": True}
This is a design assertion, not a WebRTC configuration object. Keeping it transport-neutral makes review easier: the team can challenge each semantic choice before adapters translate it into concrete APIs.
Operate the failure modes, not the channel count
Load tests should model rooms, actors, and devices separately. A test with 10,000 sockets in 10,000 rooms says little about one marketplace campaign that draws many editors and reviewers into a handful of listings. Exercise a hot room, rapid reconnects from the same actor, a receiver that stops reading, delayed packets from a retired session, and a role revocation during active movement.
Watch distributions, not a single average. Useful measures include accepted cursor updates by room, stale or duplicate drops, queue age, queue occupancy, disconnected slow consumers, authorization rejects, and time from role revocation to effective removal. Device identifiers are valuable in targeted diagnostics, but making them a permanent label on every metric creates needless cardinality. Logs or traces can hold sampled device detail while metrics aggregate by room class and result.
Set bounds before rollout. Queue capacity should be derived from a memory budget and the largest expected encoded event, while expiry should follow the maximum age at which a cursor is still visually honest. Those values belong in configuration and tests. Publishing invented universal thresholds would hide the real trade-off, because update frequency, payload size, room shape, and interface behavior determine the limits.
The nastiest shutdown case is not a clean disconnect; it is an old session remaining routable while a replacement session begins publishing from sequence zero. Treat session identity as part of the deduplication key, stop admission before draining, expire routes with ownership tokens, and test that retirement cannot remove the new owner's route. Device-scoped routing makes this race more visible, but it does not solve it automatically.
Roll out the boundary, not a rewrite
Start by separating cursor semantics from document semantics in the existing path. Add session-scoped sequence numbers, receiver-side stale rejection, bounded per-connection queues, and the failure metrics above. Then replay recorded traffic shapes with synthetic identities; do not reuse production cursor coordinates or document contents merely to make a load test realistic.
Introduce device-scoped streams only for a cohort whose requirements differ, such as restricted reviewer visibility or a distinct control policy. During migration, dual-route synthetic canary events rather than user events, compare recipient sets and stale-drop behavior, and keep one authoritative route for real traffic. Expand after reconnect, revocation, and slow-reader tests hold under the intended room distribution.
The decision rule is compact: share a logical cursor channel when audience and discard policy are shared; split by device when a device changes authorization, delivery semantics, or failure containment. Everything else is an implementation detail that should earn its operational state.
Top comments (0)