You are designing a one-way live feed of order-status updates for a web app, and the team's instinct is to reach for WebSockets. How would you decide between server-sent events, WebSockets, and periodic polling?

## Start from the traffic, not the technology The question "SSE or WebSockets?" is usually asked backwards. Four properties of the traffic decide it, and they are all knowable before any code exists: - **Direction.** Does the client send continuously, or only occasionally? Order status updates flow one way; the occasional "cancel this order" is a normal request. - **Rate and latency budget.** Ten updates a minute with a two-second tolerance is a completely different problem from a hundred a second with a fifty-millisecond budget. - **Payload.** Text, or binary frames where encoding overhead matters? - **Concurrency.** How many clients hold a connection at once, and what does each cost your server? Only after those are written down does the transport follow. ## What each option actually costs **Polling.** Least machinery: an ordinary request on a timer. No held connection, no reconnect logic, no special infrastructure, trivially debuggable and cacheable. It costs request overhead per client per interval and imposes a latency floor equal to the interval. Polling is the right answer far more often than engineers like to admit, and it is the correct baseline to argue *against* rather than skipping straight past it. **Server-sent events.** The browser opens one long-lived GET and the server writes messages as they happen. The strategic property is that **it is just HTTP**. Your existing cookie or session auth applies, CORS behaves as it does everywhere else, proxies and load balancers route it as a normal request, and your access logs and tracing see it. The client API is small, and the reconnection loop — the piece teams most often get wrong by hand — is supplied by the browser. The costs: one-way only, text only, no custom request headers from `EventSource`, and a connection held open per client. **WebSockets.** Full duplex over a persistent connection, with binary support and lower per-message overhead. That is genuinely necessary for collaborative editing, multiplayer interaction, or a chat-shaped workload. The price is a separate protocol with its own operational surface: you build reconnection and liveness checks yourself, you design an authentication scheme that fits a long-lived connection rather than a per-request one, and your edge, load balancers and observability tooling need to handle it deliberately. None of that is hard; all of it is work you do not do if the feed is one-way. ## The constraints that actually bite Four things turn a clean decision into a production incident, and a good answer names them. **Concurrent connections in the browser.** Over HTTP/1.1 a browser allows only about six connections per origin, and a stream never returns one. A user with several tabs open can exhaust the budget and stall unrelated requests to that origin. Over HTTP/2 or HTTP/3 the limit becomes concurrent streams on one connection — roughly a hundred — which removes the pressure. If you cannot serve HTTP/2 on that origin, that argues for polling or for sharing a single stream across tabs. **Concurrent connections on the server.** Every held connection is memory, a file descriptor, and usually a per-client subscription in whatever broker feeds it. A hundred thousand concurrent users on a one-message-per-minute feed is a capacity design problem regardless of which transport you choose; polling converts it into a request-rate problem instead, which some stacks absorb far more comfortably. **Intermediaries.** Anything between server and browser that buffers a response before forwarding it will hold your events until its buffer fills or the response ends — which, for a stream that never ends, means arbitrary delay. This has to be verified through the real production path, not on localhost, and it applies to any streaming approach. **Header-based auth.** The browser's `EventSource` cannot attach an `Authorization` header. If your platform is uniformly bearer-token based, either the stream endpoint accepts a cookie or a short-lived token in the URL, or you read the stream with a request you can configure — at which point you have given up the free reconnection that made `EventSource` attractive. ## The decision, stated plainly For a one-way order feed I would choose server-sent events when the updates are frequent enough that polling's latency floor is unacceptable, when the endpoint can be served over HTTP/2, and when cookie auth is available or can be. I would choose polling when updates are rare, when connection counts are large relative to what the server can hold, or when the infrastructure path cannot be trusted to stream. I would choose WebSockets when — and only when — the client genuinely needs to push a continuous stream too, and I would accept the reconnection, heartbeat and auth work as the price of that. ## Keep it reversible Whichever way it goes, the application should see a subscribe-and-unsubscribe interface, not the transport. That makes the choice a one-file change, lets you start with polling and upgrade only if measurement demands it, and gives you a fallback when a customer's corporate proxy turns out to break streaming. Deciding well matters less than making the decision cheap to revisit — and the measurement that would trigger revisiting (delivery latency, reconnect rate, concurrent connections held) should be instrumented on day one.