Problem statement
Design the presence layer for a collaborative document suite: the little colored avatars, live cursors, and "typing" dots that show who else is in a document right now and where they are working. This is the awareness signal that sits alongside the editor, not the editor itself.
Operating context. Clients open long-lived connections when they view a document and emit lightweight signals — joined, moved cursor, selected a range, actively typing, went idle, left. Every other viewer of that same document should see those signals almost immediately. Presence is soft state: it is fine to lose it on a crash as long as a stale ghost cleans itself up quickly. The document's own content sync (the OT/CRDT stream) is handled by a separate team and is out of your scope.
Out of scope. The operational-transform / CRDT document-editing pipeline, authentication and authorization, persistent storage of document content, and offline conflict resolution. Assume an auth layer hands you a trusted user identity per connection.
What to produce. A high-level architecture covering: the connection layer and wire protocol; how a presence signal fans out to every subscriber of a document; the ephemeral data model and how heartbeats plus TTLs evict ghosts; how you shard connections and presence state so a single hot document does not melt one node; and the failure story when a presence node dies. Sketch the components and the path a cursor move takes from one client to all the others; we will probe specifics in checkpoints.
Functional requirements
- Report the set of users currently active on a given document, each with a display name and avatar reference.
- Broadcast each user's live cursor position and text-selection range to the other viewers of the same document.
- Emit join and leave events within a bounded delay so a viewer who closed their tab disappears from the roster.
- Expose a per-user indicator distinguishing actively editing from idle, derived from recent input.
- Let a client subscribe to a document's presence and receive an initial roster snapshot followed by incremental deltas.
Non-functional requirements
- Support 5 million concurrently connected clients across all documents at peak.
- Deliver a presence update to all subscribers of a document within p99 300 ms of the originating signal.
- A typical document has fewer than 50 concurrent editors, but the hottest can reach 10000 passive viewers.
- Presence is ephemeral: tolerate loss on node failure provided a stale entry self-heals within 30 s.
- 99.9% availability for the subscribe path; a presence outage must never block document editing.
- Sustain 500000 presence signals/sec (cursor moves, edits, heartbeats) at steady state.
Topics
- System Design HLD
- Realtime Websocket
- Data Ephemeral
- Scaling Fan-Out
- Infra Pubsub