Collaborative cursors

Before any cursors move, decide what a connection means. A WebSocket is a long-lived, stateful, full-duplex pipe — unlike HTTP, the server now holds per-socket state and must reason about its lifecycle (open → message → close). Model presence as ephemeral state keyed by a session id: who is here, their name, color, and last cursor. Define a small binary or JSON message envelope ({type, sessionId, payload}) and a heartbeat (ping/pong every ~15 s) so dead sockets are detected, not leaked. At this stage one cursor update is one message; a 10-person room at 60 Hz raw input would be 600 msgs/s inbound, which is exactly why later milestones throttle.

Every message from one client must reach the other N−1 clients in the same room — and naive fan-out is O(N²): in a 50-person room, each of 50 senders at even 20 msgs/s produces 50×49×20 ≈ 49k message-sends/s on one server. Contain it by isolating state per room (a room owns its socket set and presence), and by fanning out only to that room, never the whole server. Decide the relay rule: echo-to-others (sender already rendered locally) and skip the originator. Keep the per-room broadcast loop off the critical accept path so a hot room can't stall new connections.

Raw pointer events fire faster than anyone can use — up to 120 Hz on a high-refresh display — and the network can't (and shouldn't) carry that. On send, throttle outgoing cursor updates to a fixed cadence (~50 ms / 20 Hz) and coalesce: if three moves queue before the next tick, send only the last position, not all three. On render, the remote stream arrives jittery and sparse, so interpolate between the last two received points (lerp toward the target each animation frame) so a cursor that updates at 20 Hz still glides at display refresh. Drive rendering from requestAnimationFrame, not from each inbound message, so a burst can't thrash layout.

Cursors are last-writer-wins by nature — a newer position simply replaces the old. But shared selections and any shared mutable state need an explicit conflict rule, because two clients can mutate concurrently and messages arrive out of order. Start with LWW keyed by a logical timestamp (a Lamport counter, not wall-clock, since unsynced clocks lie): each presence field carries a counter, and a receiver ignores any update with a counter ≤ what it already has, making the merge commutative and idempotent. This is enough for per-user selection state. For genuinely shared editable content (the stretch), LWW drops writes, so you need a CRDT.

Networks drop. When a socket closes, the client must reconnect with exponential backoff + jitter (so 1000 clients knocked off by a deploy don't reconnect in a synchronized thundering herd), and on reconnect resync the full room snapshot rather than replaying a missed delta stream — for ephemeral presence, a fresh snapshot is correct and cheap. On the server, a slow consumer is dangerous: if you keep queuing fan-out messages for a socket whose send buffer is full, memory grows unbounded. Apply backpressure — watch socket.bufferedAmount and, past a threshold, drop coalescible cursor frames (they're stale anyway) rather than buffer them, or disconnect the laggard.

One WS server caps out (file descriptors, CPU on fan-out) long before your user count does, so put two or more behind a load balancer with sticky sessions and bridge them with a pub/sub backplane (Redis pub/sub or similar): a message lands on server A, publishes to a per-room channel, and every server with members of that room re-fans-out locally. Now instrument it — emit RED metrics (connection rate, message errors, fan-out duration) per room and propagate a trace across the publish hop — because without numbers an incident is invisible. Then trigger one: a runaway client (or a feedback echo bug) floods a room, the backplane amplifies it across all servers, fan-out duration p99 spikes and CPU saturates. Detect it on your dashboard, mitigate live (per-connection rate limit + room message cap), and find the root cause.