Polling vs SSE vs WebSocket: Pick the Simplest Transport That Meets the Need

When a product manager says we need real-time, the engineer's first job is to find out what they actually mean. The answer usually picks the transport, and the wrong transport quietly haunts you for years.

Polling is the cheapest option that exists. The client asks the server every N seconds. The server answers. That is the entire system. It uses your existing HTTP stack, your existing auth, your existing observability. Caches and conditional requests with ETag or If-Modified-Since make most of those calls free. The downsides are obvious: latency is bounded below by the poll interval, and a thousand clients polling on the same wall clock minute create a thundering herd. Add jitter and you have already solved the second problem. Use long polling if you want lower latency without leaving HTTP.

Server-Sent Events are the right answer more often than people realize. The client opens one HTTP connection, the server streams events on it forever. It is one-way, server to client, which is exactly what notifications, live feeds, progress bars, model token streams, and most dashboard updates need. The transport is plain HTTP, so proxies, load balancers, gateways, and auth middleware all work without special configuration. The protocol has built-in reconnection with a Last-Event-ID header for replay. There is no framing protocol to debug. If you are reading this and your only requirement is push updates to the user, you probably want SSE.

WebSockets earn their cost when the data flow is genuinely bidirectional and latency sensitive. Chat, collaborative editing, multiplayer cursors, trading clients, anything where the client sends frequent messages and expects fast acknowledgements. Once you commit you also commit to the operational tax: sticky sessions, connection state, backpressure, idle timeouts at every proxy in the path, and a reconnect-with-replay protocol you have to design yourself because the spec does not give you one.

A useful production note on caching. SSE plays well with HTTP caches and CDNs because the protocol is just HTTP. WebSockets do not. Cache and edge layers are a wall the WebSocket has to tunnel through, usually at significant cost. If your update fan-out is large and read-heavy, SSE behind a CDN can serve a million subscribers from far cheaper infrastructure than the equivalent WebSocket fleet.

The decision is mechanical. If updates are infrequent or stale data is acceptable, poll. If you only push server to client, use SSE. Reach for WebSockets when the client genuinely needs to push too. Most products do not on day one.