In a Node.js chat room, broadcast each cursor position as a throttled, ephemeral update without persisting it. TL;DR: throttle motion per user in the client, enforce a second ceiling at the Express server, publish only accepted samples, and drop excess samples rather than queueing or storing them. Reconnect durable chat from a checkpoint, but let the next live cursor event replace every cursor state that was missed.

That separation is the operational choice. A collaborative editor has two recovery classes even when both appear in the same room: messages and edits may require backfill; cursor motion does not. Persisting both creates retention and deletion work without making the recovered room more correct.

The incident-shaped failure to design out is stale delivery. If cursor samples share a durable queue with chat, recovery can replay old coordinates after newer motion has arrived. The system is technically delivering everything and visibly doing the wrong thing.…