System design3 min

WebSockets & Long Polling

Standard HTTP is stateless and unidirectional: the client requests, and the server responds. But what happens when you need real-time updates—like a chat app, live sports scores, or a collaborative editor?

You have a few architectural options: Short Polling, Long Polling, Server-Sent Events (SSE), and WebSockets.

1. Short Polling

The simplest approach: the client asks the server for updates every N seconds.

How it works:

  1. Client: "Any new messages?"
  2. Server: "No."
  3. (Waits 5 seconds)
  4. Client: "Any new messages?"
  5. Server: "Yes, here is Message A."

Pros: Trivial to implement. Cons: Massive overhead. Most requests return empty, wasting server CPU, bandwidth, and battery life on mobile devices.

2. Long Polling

An optimization of short polling to reduce empty responses.

How it works:

  1. Client makes an HTTP request.
  2. The server holds the connection open until it actually has new data to send.
  3. Server sends the response.
  4. The client processes the data and immediately opens a new long-polling request.

Pros: Real-time feel without the massive overhead of empty short-polling requests. Cons: Still carries HTTP header overhead for every message. Connection timeouts can be tricky to manage.

3. Server-Sent Events (SSE)

SSE is a standardized HTTP feature that allows a server to push data to the client over a single, long-lived HTTP connection.

How it works:

  1. Client makes an HTTP request.
  2. Server responds with a text/event-stream content type.
  3. The connection stays open indefinitely, and the server pushes text-based events down the pipe whenever it wants.

Pros: Built-in browser support (EventSource API), automatic reconnection, respects standard HTTP (so it works easily through proxies and load balancers). Cons: Strictly unidirectional (Server to Client only). If the client needs to send data, it must make a separate standard HTTP POST request. Only supports UTF-8 text (no binary). Maximum open connections per browser are limited (historically 6 per domain over HTTP/1.1).

4. WebSockets

WebSockets provide a persistent, bi-directional, full-duplex communication channel over a single TCP connection.

How it works:

  1. Client makes a standard HTTP request to the server with an Upgrade: websocket header.
  2. If the server supports it, it accepts the upgrade.
  3. The HTTP protocol is "peeled away," leaving a raw TCP socket.
  4. Both client and server can now freely stream binary or text data back and forth simultaneously.

Pros: Extremely low latency. Minimal overhead (no HTTP headers on every message). True bi-directional communication. Supports binary data. Cons: More complex to load balance (requires sticky sessions or a pub/sub backplane like Redis). State management is harder (if a server crashes, you lose all connected clients).

Summary: Which one to use?

  • Use WebSockets for highly interactive, bi-directional real-time apps (Multiplayer games, Chat, Collaborative editing).
  • Use SSE when you only need to push data to the client (Live stock tickers, Twitter feeds, Notifications).
  • Use Long Polling as a fallback if corporate firewalls block WebSockets.