Question 1

When should you use Server-Sent Events vs. WebSockets?

Accepted Answer

Use Server-Sent Events (SSE) when communication is server-to-client only: live dashboards, activity feeds, notifications, progress bars, stock price updates. SSE uses a single long-lived HTTP connection; the browser's EventSource API handles reconnection automatically. Works through HTTP proxies and load balancers without special configuration; works over HTTP/2 (multiple SSE streams share one TCP connection). Use WebSockets when you need full-duplex (both sides send): chat applications, collaborative document editing, multiplayer games, live trading platforms. WebSockets have lower per-message overhead (2-6 byte frames vs. HTTP headers) and sub-millisecond latency. The trade-off: WebSockets require WebSocket-aware infrastructure (proxies, load balancers) and are stateful (connections pin to one server).

Question 2

How do you scale WebSocket connections across multiple servers?

Accepted Answer

WebSocket connections are long-lived and stateful — each connection is pinned to one server. Two approaches to horizontal scaling: (1) Sticky sessions: the load balancer routes all requests from a client to the same server (via IP hash or session cookie). Simple but creates hot spots — if one server has many active users, it is overloaded while others are idle. No failover (server death drops all its connections). (2) Pub/sub fan-out: each server subscribes to a shared message bus (Redis Pub/Sub, Kafka). When a message must be sent to client X, any server publishes to the bus; the server holding client X's connection delivers it. This decouples connection management from message delivery — any server can send to any client regardless of which server holds the connection. The pub/sub approach is preferred for high-scale systems.

Question 3

What are the disadvantages of long polling?

Accepted Answer

Long polling simulates server push using standard HTTP: the client sends a request; the server holds it open until data is available; the client immediately re-requests after receiving a response. Disadvantages: (1) connection overhead — each client maintains one in-flight HTTP request, consuming a server thread or file descriptor for the hold duration; at 10,000 concurrent users, 10,000 connections are held open; (2) HTTP header overhead — each response re-sends full HTTP headers (200-800 bytes) for potentially tiny payloads; (3) latency floor — each message delivery requires a full request-response round trip plus server hold time; (4) scale complexity — held requests consume connection limits on load balancers and proxies. Use long polling only when WebSockets and SSE are blocked by infrastructure constraints (strict corporate proxies that strip Upgrade headers).

Question 4

How does Socket.io handle real-time connection fallbacks?

Accepted Answer

Socket.io automatically negotiates the best available transport: it starts with long polling (universally supported) and upgrades to WebSockets if the client and infrastructure support it. The upgrade is transparent to application code — you write Socket.io event handlers once and they work regardless of transport. This handles corporate proxies that block WebSocket Upgrade headers by falling back to long polling without any client-side code changes. Socket.io also handles reconnection, heartbeats, and room-based pub/sub. The trade-off: Socket.io adds ~45KB gzipped to the client bundle and requires a Socket.io-compatible server (not a raw WebSocket server). For new projects that can guarantee WebSocket support (modern browsers, no restrictive proxies), native WebSockets avoid the dependency.

Real-Time Communication Patterns: Long Polling, SSE, WebSockets

Long Polling

Server-Sent Events (SSE)

WebSockets

Scaling Persistent Connections

Choosing the Right Pattern