WebSockets vs Polling vs Server-Sent Events: Picking Realtime Transport

Realtime features show up everywhere now: live dashboards, chat, collaborative editing, notifications, stock tickers, delivery tracking. The transport you pick for those features shapes your server architecture, your scaling story, and your debugging experience for years. The three serious options on the web platform are polling, Server-Sent Events, and WebSockets. They are not interchangeable, and the right choice depends on the direction of traffic, the latency you need, and how much infrastructure complexity you are willing to carry.

Start with the shape of the traffic

Before comparing protocols, describe the traffic. Four questions settle most decisions:

1. Who talks first, and how often? If the server pushes updates on its own schedule, you need a server to client channel. If the client mostly asks and the server answers, plain requests may be enough.
2. Does the client also send messages, or only receive? A chat app is bidirectional. A price ticker is server to client only.
3. How fresh must the data be? A notification that arrives a few seconds late is fine. A collaborative cursor that lags by seconds is unusable.
4. How many concurrent connections will you hold? Ten thousand idle connections and ten thousand connections sending messages every second are very different scaling problems.

With those answers in hand, the comparison becomes concrete rather than a matter of taste.

Polling: simple, and more expensive than it looks

Polling means the client asks the server on a timer: every few seconds it sends a request, and the server answers with the latest state. Short polling uses a fixed interval. Long polling holds the request open until new data arrives or a timeout fires, then the client immediately opens another request.

Polling wins on simplicity. It is ordinary HTTP, so it works through every proxy, load balancer, and firewall without special configuration. It is stateless on the server, which means any instance can answer any request, horizontal scaling is trivial, and a crashed server loses nothing. Debugging is easy because every interaction is a normal request you can log, replay, and inspect in browser developer tools.

The cost is paid in latency and wasted work. With a five second interval, the average update arrives two and a half seconds late, and the worst case is five seconds. Shorten the interval to one second and the latency improves, but now every client sends sixty requests a minute, most of which return "nothing new". At scale that is real load: request parsing, authentication, database checks, and response serialization, multiplied by every connected client, almost all of it thrown away. Long polling removes most of the empty responses, but it holds a connection open per client, which reintroduces the connection management problem, and it still pays the cost of a new request and re-authentication on every event.

Polling is the right choice when updates are infrequent, latency tolerance is measured in seconds, and simplicity matters more than efficiency. A dashboard that refreshes every thirty seconds, a job status page, or an admin panel are all fine with polling. It is the wrong choice for chat or live collaboration, where the request volume and the latency both hurt.

Server-Sent Events: the underused middle ground

Server-Sent Events, or SSE, give you a one way stream from server to client over a plain HTTP connection. The client opens a request, the server keeps it open, and sends events as text lines whenever there is something new. The browser API is small: an EventSource object, a message handler, and automatic reconnection with a last event ID so the server can replay missed events.

SSE keeps the operational advantages of HTTP. It works through proxies and load balancers with far less special configuration than WebSockets, it flows over the same TLS and authentication setup as the rest of your API, and each event is a simple text frame that is easy to log. The browser handles reconnection for you, which removes a whole class of client bugs. On the server, SSE still holds one connection per client, so you need an event loop or async runtime that can hold many idle connections cheaply, but you do not need a separate WebSocket infrastructure.

The limits are real and worth stating plainly. SSE is server to client only. If the client needs to send data, it does so with separate HTTP requests, which is fine for many designs but awkward for true bidirectional interaction. Browsers cap the number of simultaneous SSE connections per origin, historically around six, which matters if a single page opens several streams. Binary data must be encoded as text, so SSE is a poor fit for binary payloads. And some proxies buffer responses, which can delay events unless buffering is disabled for the stream endpoint.

Here is the shape of an SSE endpoint in a Node.js server, to show how little machinery it needs:

app.get("/events", (req, res) => {
  res.writeHead(200, {
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    Connection: "keep-alive",
  });
  const timer = setInterval(() => {
    res.write(`data: ${JSON.stringify({ time: Date.now() })}\n\n`);
  }, 1000);
  req.on("close", () => clearInterval(timer));
});

SSE is the right choice for server to client streams where the client rarely talks back: live feeds, notifications, progress updates for a long running job, sports scores, price tickers. If you are reaching for WebSockets for a feed that never takes client input, SSE is almost certainly simpler and sufficient.

WebSockets: full duplex, full responsibility

WebSockets start as an HTTP request that upgrades to a persistent, bidirectional, message based connection. After the upgrade, either side can send messages at any time, with low overhead per message and no HTTP request and response cycle per event. That is the lowest latency option of the three, and the only one designed for genuinely bidirectional traffic.

That power comes with operational responsibility. A WebSocket connection is stateful: the server holding it must deliver messages to that client. Scaling to multiple instances therefore needs a routing mechanism, usually a publish and subscribe backbone such as Redis, so an event arriving at instance A can reach a client connected to instance B. Rolling deploys must drain connections gracefully, and both sides need ping and pong handling to detect dead connections, plus client reconnection logic with backoff, because unlike SSE the browser will not reconnect for you.

The client side is straightforward in modern browsers:

const socket = new WebSocket("wss://example.com/chat");
socket.addEventListener("open", () => {
  socket.send(JSON.stringify({ type: "join", room: "general" }));
});
socket.addEventListener("message", (event) => {
  const payload = JSON.parse(event.data);
  renderMessage(payload);
});

WebSockets are the right choice for chat, multiplayer interaction, collaborative editing, and any feature where both sides send messages frequently and latency matters. They are the wrong choice when traffic is one way, because you pay the stateful infrastructure cost without using the bidirectional capability.

A decision guide you can actually use

The choice can be reduced to a short decision path:

1. If updates are infrequent and a few seconds of delay is acceptable, use polling. Keep it until the request volume or the latency requirement forces a change.
2. If the server pushes updates and the client rarely sends anything back, use SSE. It gives you streaming with HTTP operational simplicity.
3. If both sides send messages, or latency must be well under a second in both directions, use WebSockets, and budget for the connection routing and reconnection work that comes with them.

Two edge cases deserve a note. If your traffic must pass through corporate proxies that interfere with long lived connections, polling may be the only option that works reliably, and reliability beats elegance. If you need ordering guarantees across reconnections, none of these transports gives you that for free: you need application level sequence numbers and a replay mechanism, whether you build it on SSE last event IDs or on your own WebSocket protocol.

Scaling notes that apply to all three

Whatever you choose, three scaling concerns recur. First, authentication: a long lived connection is authenticated once at setup, so token expiry mid connection needs a plan, such as revalidating on a timer or issuing connection scoped credentials. Second, backpressure: a slow client must not let the server accumulate an unbounded queue of unsent events, so you need a policy for dropping, coalescing, or disconnecting slow consumers. Third, observability: count connections, message rates, and reconnect rates per instance, because realtime failures often show up as a slow rise in reconnects long before users report anything.

Realtime transport is not a fashion choice. Polling is simple and stateless, SSE is the efficient one way stream that many teams overlook, and WebSockets are the full duplex tool with a real operational cost. Match the transport to the direction and urgency of your traffic, and you will get a system that is as simple as the feature allows and no simpler.