Real-Time Communication Overview
Real-time communication pushes data to clients as it happens, rather than waiting for them to ask. Four technologies dominate: WebSockets (bidirectional, persistent), Server-Sent Events (server-to-client only, simpler), WebRTC (peer-to-peer, audio/video), and long polling (HTTP fallback). Choosing the right one depends on directionality (one-way vs two-way), latency requirements, browser support, and infrastructure complexity.
How it works
Real-time communication means the server pushes data to the client as it happens, rather than the client asking repeatedly. The fundamental alternative is polling: the client asks "anything new?" every second. Polling works but is wasteful (most polls return nothing) and adds latency (you only see updates on the next poll).
Four real-time technologies are commonly used:
- WebSockets: persistent, bidirectional TCP connection. Client and server send messages any time. The standard for chat and interactive apps.
- Server-Sent Events (SSE): persistent, server-to-client only. Server pushes events over HTTP. Simpler than WebSockets; good for live feeds.
- WebRTC: peer-to-peer, typically for audio/video. Bypasses the server for media, with the server brokering the initial connection.
- Long polling: HTTP fallback. Client makes a request; server holds it open until data is available; client immediately re-polls. Works everywhere, more overhead.
WebSockets are the standard for bidirectional real-time. The connection starts as an HTTP request with an Upgrade header; the server responds with 101 Switching Protocols; from then on, it's a persistent TCP connection where either side can send messages at any time.
Pros: bidirectional, low latency (no per-message HTTP overhead), works through most firewalls (uses port 443/80). Cons: requires WebSocket-aware infrastructure (load balancers, proxies), server holds connection per client (memory), no built-in reconnection or backpressure (you build it).
Use when: chat, collaborative editing, multiplayer games, interactive dashboards. Anywhere the client sends data frequently and the server pushes events.
The scaling challenge: each connected client holds a connection. A single server handles ~10k-65k connections (memory-bound). For more, you need horizontal scaling with a pub/sub backend (Redis, NATS) to fan messages across servers — any server can publish, all servers receive and forward to their connected clients.
Server-Sent Events (SSE) is the simpler alternative when the server pushes and the client only listens. It's a standard HTTP response with Content-Type: text/event-stream. The server writes events as data: <payload>\n\n. The browser's EventSource API handles reconnection automatically.
Pros: simple (it's HTTP), auto-reconnect built into the browser, works through any HTTP infrastructure (CDNs, proxies), no special protocol. Cons: one-way only (server→client), limited connections per domain in some browsers (6 in HTTP/1.1; unlimited in HTTP/2).
Use when: live feeds (stock prices, scores), notifications, status updates, anything where the client just listens. For these use cases, SSE is simpler and more robust than WebSockets.
The hidden advantage: SSE works with HTTP/2 multiplexing, so multiple SSE streams share one TCP connection — no head-of-line blocking, no per-stream connection limit. With HTTP/2, SSE scales much better than the old HTTP/1.1 limitation suggested.
WebRTC isn't a server-push technology; it's a peer-to-peer protocol for real-time media (audio, video, data) between browsers. The server's role is signaling: brokering the initial connection between two peers. Once connected, media flows directly between peers, bypassing the server's bandwidth. This is how Google Meet, Zoom, and Discord voice channels work — the server doesn't stream gigabytes of video; peers exchange it directly. Use WebRTC for video calls, screen sharing, and peer-to-peer gaming. Don't use it for chat or notifications — that's WebSockets' job. WebRTC has complex sub-protocols (STUN, TURN, ICE) for NAT traversal; the SDP offer/answer exchange happens via your signaling channel (often WebSockets).
Decision rule for picking the technology:
- Do I need audio/video between users? → WebRTC. Nothing else does this efficiently.
- Do I need the client to send data to the server frequently? (chat, collaborative editing, game input) → WebSockets.
- Does the server just push events to the client? (live scores, notifications, status) → SSE.
- Does my infrastructure not support persistent connections? (legacy corporate proxies) → long polling as a fallback.
- Do I need to support very old browsers? → long polling, with feature detection to upgrade.
For new apps, the choice is almost always WebSockets or SSE. Long polling is legacy; WebRTC is specialized for media. Don't reach for WebSockets if SSE suffices — SSE's simplicity (auto-reconnect, HTTP semantics, CDN compatibility) is a real win.
You're building a live stock price dashboard. The server has new prices every few seconds; the client just displays them. Which technology is the simplest fit?
Pick one answer.
Your chat app uses WebSockets. You're scaling to 100k concurrent users. A single server holds ~10k connections. What's the architecture?
Pick one answer.
Why would you use WebRTC instead of WebSockets for a video call?
Pick one answer.
Engineering mental model
Mental model. Think of Real-Time Communication Overview as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Real-Time Communication Overview mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing Real-Time Communication Overview, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
// Pseudocode
request = receive()
result = real_time_overview(request)
return result
// Production questions:
// 1. What happens on timeout?
// 2. Can this operation be retried safely?
// 3. What is the bottleneck?Back-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: Real-Time Communication Overview
Change the variables below and predict what breaks first in Real-Time Communication Overview. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on Real-Time Communication Overview, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using Real-Time Communication Overview. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using Real-Time Communication Overview?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses Real-Time Communication Overview, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose Real-Time Communication Overview, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
A useful engineering lens for Real-Time Communication Overview: define the problem it solves, the simpler design that fails first, the constraint that forces you to introduce this concept, and the new failure modes the concept creates.
Numerical sanity check
Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
Imagine the simplest version of a system using Real-Time Communication Overview. What breaks first as traffic grows by 10×, and what would you change before reaching 100×?
Pick one answer.
What you gain, what you pay
- +Push model gives low latency (no polling delay).
- +WebSockets: bidirectional, low overhead per message.
- +SSE: simple, auto-reconnect, works with HTTP infrastructure.
- +WebRTC: peer-to-peer media without server bandwidth costs.
- −Persistent connections are stateful — harder to scale than stateless HTTP.
- −WebSockets need WebSocket-aware infrastructure (LBs, proxies).
- −SSE is one-way only — client can't push back.
- −WebRTC is complex (NAT traversal, STUN/TURN, ICE) — high implementation cost.
How this breaks in production
- Using WebSockets when SSE suffices — unnecessary complexity.
- Using WebRTC for chat — wrong tool, much harder than needed.
- Scaling WebSockets without a pub/sub backend — messages don't cross servers.
- Long polling fallback consuming server threads (one thread per held request).
Don't fall into these traps
- •Defaulting to WebSockets for everything — SSE is simpler for server-push.
- •Forgetting connection lifecycle (reconnect, heartbeat, cleanup).
- •Not planning horizontal scaling for WebSocket connections.
- •Polling every second for updates that should use SSE.
Real systems using this
How real systems implement this
- Slack — Uses WebSockets for chat messages (bidirectional, low latency). The signaling for Slack Huddles (voice) uses WebRTC for peer-to-peer audio after the WebSocket-based handshake.
- Twitter live notifications — Server-Sent Events for the notification stream — server pushes events as they happen, browser's EventSource auto-reconnects on failure. Simple, robust, perfect for one-way push.
Practice saying it out loud
- Q1Compare WebSockets, SSE, WebRTC, and long polling. When would you use each?
- Q2How do you scale WebSockets to 100k concurrent users?
- Q3Why is WebRTC peer-to-peer, and what's the server's role?
- Q4What's the simplest way to push server events to a browser?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
WebSockets — Full-Duplex Real-Time Over TCP