WebSockets vs SSE vs Polling

Chat. Live scores. Notifications. Collaborative editing. Any feature where the server pushes data to the client the moment it's ready. HTTP was designed for the opposite: client asks, server answers. To make push happen, you pick one of three techniques: polling, Server-Sent Events (SSE), or WebSockets. Each has radically different resource costs, browser support, and failure modes.

"Use WebSockets" is the lazy answer. Often SSE is better. Sometimes plain polling is enough. Know which trade-off you're making.

An SSE endpoint is just an HTTP endpoint that never closes. Set Content-Type: text/event-stream, stream text events separated by blank lines. Browsers handle it via new EventSource(url).

event: message
id: 42
data: {"user":"alice","text":"hi"}

event: heartbeat
data: ping

Free auto-reconnect: if the connection drops, the browser reconnects and sends Last-Event-ID: 42 so the server resumes from where it left off. Works through firewalls that don't like WebSockets. Runs over HTTP/2 for multiplexing.

Use SSE when updates flow server → client. Most "real-time" features (news feed, dashboards, status pages) actually are one-way. WebSockets add complexity you don't need.

A WebSocket is a long-lived TCP connection. That's great for latency, terrible for infrastructure:

• Sticky connections. A user's WS lands on server 3. A new message for that user arriving at server 7 needs a pub/sub fabric (Redis, Kafka) so server 3 can pick it up.
• No REST-style horizontal scaling. 1M concurrent users = 1M open sockets = your server fleet must hold state. Restarting a node drops thousands of connections.
• Load balancers hate them. Most LBs have default idle timeouts of 60s; WS needs heartbeats (ping/pong frames) to stay alive. Forget to configure and users drop every minute.
• TLS termination gets weird. Some proxies close idle WS after 5 minutes. Some strip WS upgrade headers. Always test your prod path end-to-end.
• Reconnect logic is on you. Unlike SSE, WS has no built-in "last event ID." Your app resends the last-seen timestamp on reconnect and the server backfills.

Real WebSocket systems (WhatsApp, Discord, Slack) have specialized WS gateway fleets, pub/sub backbones, and careful connection-draining on deploy. It's an order of magnitude more infra work than SSE.

WhatsApp (WebSockets + custom protocol). Notification system (WS for user clients + SSE for web dashboard). Video conferencing (signaling over WS, media over WebRTC/UDP). PUBG (UDP for game state; WS fallback). Stock trading (WS for live quotes).