WebSockets vs Polling: When to Use Real-Time and When Not To

HTTP is a request-response protocol — the client sends a request, the server sends a response, the connection closes (or is kept alive for reuse, but the model is still request-response). The server cannot initiate communication; it can only respond. WebSockets are a persistent, full-duplex protocol — after an initial HTTP handshake that upgrades the connection, both client and server can send messages at any time without the other initiating. This enables true push from server to client. The WebSocket connection stays open for the lifetime of the session, consuming a file descriptor on both ends. This is the core tradeoff: real-time server push is powerful but has a persistent resource cost.

SSE is a one-directional protocol: the server streams data to the client over an HTTP connection, but the client can't send data back on the same connection. For server-to-client real-time streaming where the client doesn't need to send messages back — live sports scores, stock prices, notification feeds, log streaming — SSE is simpler than WebSockets. It works over standard HTTP/2 connections, automatically reconnects when disconnected, has built-in event IDs for resuming after disconnection, and requires no special protocol handling. WebSockets are appropriate when you need bidirectional real-time communication: chat, collaborative editing, multiplayer games. Use SSE when you only need server push; WebSockets when you need both directions.

WebSocket connections are persistent and stateful. A server maintaining 10,000 simultaneous WebSocket connections uses 10,000 file descriptors and memory for each connection's state. If you're running multiple server instances, a WebSocket client must reconnect to the same server (sticky sessions) or use a shared message broker (Redis Pub/Sub, Kafka) so any server instance can push messages to any connected client. HTTP requests are stateless — any load-balanced server can handle any request. WebSocket connections must be managed across your entire server fleet. Services like Pusher, Ably, and AWS API Gateway WebSocket API exist specifically to handle WebSocket scaling so you don't have to manage this infrastructure yourself.