Real-time Systems Development: WebRTC, SSE, WebSocket
On one project — an online auction platform — we used polling every 2 seconds. Under load from 400 simultaneous auction participants, the server received 12,000 HTTP requests per minute just to find out the current bid. 90% of responses returned the same data. Switching to WebSocket reduced load by 15x without changing UX.
Choosing Transport for the Task
Three main real-time mechanisms differ not only technically but operationally.
Server-Sent Events work over regular HTTP/1.1 or HTTP/2. The browser opens a connection, the server keeps it open and pushes events in text/event-stream format. Automatic reconnection is built into the browser — no need to write reconnect logic. Limitation: only server → client. Ideal for notifications, progress of long tasks, live feeds.
WebSocket — full-duplex channel after HTTP Upgrade handshake. Browser and server exchange frames in both directions. Suitable for chats, collaborative editing, games, trading terminals. Requires separate handling of reconnect logic and heartbeat (ping/pong every 30 seconds, otherwise NAT tables close the connection).
WebRTC — peer-to-peer audio/video and data between browsers directly, bypassing the server. Server is only needed for signaling (STUN/TURN to bypass NAT). In practice, TURN server is needed in approximately 20–30% of cases (corporate networks, symmetric NAT), this is important to account for in infrastructure.
Collaborative Editing — the Most Complex Part
Collaborative editing is not just "whoever wrote last wins". It's Operational Transformation or CRDT (Conflict-free Replicated Data Types).
Without a collision merge algorithm: two users edit a document simultaneously, both insert text at position 45. The first saves — position shifts. The second saves on top — their operation is applied to stale state. Text either duplicates or is lost.
Yjs — the most mature CRDT library for the browser. Integrates with ProseMirror, TipTap, CodeMirror, Monaco Editor. Synchronization providers: y-websocket for WebSocket backend, y-webrtc for P2P without server. Persistence — y-indexeddb for local cache, y-leveldb on server.
In practice: TipTap (ProseMirror wrapper) + Yjs + y-websocket + Hocuspocus (Node.js WebSocket server for Yjs with PostgreSQL persistence) — standard stack for collaborative text editor. Hocuspocus out of the box provides document-level authorization, awareness (who's editing now), persistence through any storage.
The problem almost everyone faces: Yjs document size grows over time due to operation history. Needs periodic garbage collection — document snapshot + cleanup of old operations. Without this, a document worked on for a year can weigh 50MB.
WebSocket Scaling
One WebSocket server holds connections in memory. If you have two instances behind a load balancer — a user on instance A won't receive a message addressed through instance B. Standard solution: Redis Pub/Sub as a bus between instances. Socket.io out of the box supports @socket.io/redis-adapter.
Sticky sessions (IP hash on Nginx) — alternative, but creates uneven load distribution and doesn't help if an instance falls.
For very high loads (100k+ simultaneous connections) — separate WebSocket gateway (Pushpin, Centrifugo, Ably) in front of the main API. Centrifugo is written in Go, holds 1M+ connections on a single server and integrates with any backend via HTTP API.
Typical Implementation Problems
Memory leak on server. Forgot to remove event handler when connection closes. On Node.js this shows through process.memoryUsage() — heap grows ~1MB per hour. EventEmitter warns about 10+ listeners, but not always noticed.
Thundering herd on reconnect. Server fell for 30 seconds, came up — 10,000 clients try to reconnect simultaneously. Exponential backoff with jitter is mandatory: delay = Math.min(baseDelay * 2^attempt + random(0, 1000), maxDelay).
No indication of connection loss. WebSocket doesn't always notify of disconnection (e.g., phone goes into tunnel). Heartbeat: client sends ping every 25 seconds, if pong doesn't arrive within 5 seconds — reconnect.
Work Process
We start by choosing transport for specific use cases — sometimes one project needs all three: SSE for system notifications, WebSocket for chat, WebRTC for video calls. We design message protocol (usually JSON with type and payload, rarely binary via MessagePack). We develop with full testing of race conditions — this is what unit tests usually don't cover.
Load testing with k6 + k6/experimental/websockets: we model a scenario of 5,000 simultaneous connections with real message sending patterns.
Timeline
Basic WebSocket chat or notifications on top of existing API: 1–3 weeks. Collaborative editor with Yjs and persistence: 4–8 weeks. WebRTC video calls with recording: 6–12 weeks, significant part — integration with media server (mediasoup, Janus).