Why not plain requests
Polling with ordinary requests adds latency and waste because the client cannot know when a peer has typed. A WebSocket gives a single long lived full duplex connection where the server can push edits the instant they arrive.
What flows over it
- Document operations that must be ordered and acknowledged.
- Awareness updates that are frequent and disposable.
- Heartbeats that detect dead connections and trigger cleanup.
Scaling concerns
A single server holds many sockets in memory, so horizontal scaling needs a pub sub backplane. When a client connected to server one edits, the operation is published so server two can push it to its own clients. Sticky routing keeps a document's clients co located where practical to cut cross node chatter.
Back pressure matters too: if a client falls behind, the server must buffer or drop awareness while never dropping ordered document operations.
Key idea
WebSockets give a persistent duplex channel for instant edit push, with a pub sub backplane and back pressure rules to scale across nodes.