Reqflow
← All concepts
Communication·3 min read

Long-Polling vs WebSockets vs SSE

Three ways to deliver server-pushed updates; pick based on direction, scale, and infra constraints.

Try it

Pick a scenario below and see which option fits, and why.

Polling
ask on a timer
WebSockets
persistent two-way push
Scenarios

There is no universal winner here, only the right fit for a given situation. Each scenario above pushes the decision a different way, which is exactly how this tradeoff shows up in real design questions.

First time reading this? Start here

Plain English: how do you let the SERVER push something to the browser (instead of the browser asking repeatedly)? Three answers: poll often (simple, wasteful), keep a one-way pipe open (SSE), or open a two-way pipe (WebSocket). Each has its place.

Used in:WhatsAppChatDropbox

What it is

Three techniques for server-to-client updates over HTTP: long-polling (client opens a request, server holds it until data is ready, then closes), WebSockets (bidirectional persistent TCP connection upgraded from HTTP), Server-Sent Events (one-way HTTP stream from server to client over a single long connection).

The problem it solves

HTTP is request-response, so the client has to ask. For 'tell me when something happens' use cases (chat messages, notifications, live updates), you need a way for the server to push.

How it works

Long-polling: client makes a request, server holds it (up to ~30s) until data appears or it times out, then client reconnects. WebSockets: HTTP upgrade handshake, then a persistent TCP connection both sides can write to. SSE: server holds a single HTTP response open and writes events to it, giving a one-way, simple stream with auto-reconnect built-in.

Why use it

  • Long-polling: works through any HTTP proxy/firewall, no special infra
  • WebSockets: lowest latency, bidirectional, lowest overhead per message
  • SSE: simpler than WebSockets, auto-reconnect, works over standard HTTP

What it costs you

  • Long-polling: high overhead, with a new HTTP request after every message
  • WebSockets: requires sticky routing; many corporate proxies block them
  • SSE: one-way only (server → client); for client → server you still need POST

Where it shows up in our architectures

  • WhatsApp →

    WebSockets: bidirectional, low-latency message delivery

  • Chat →

    WebSockets via the gateway tier; pub/sub for cross-box fanout

  • Dropbox →

    Long-polling for sync notifications, which works through every corporate firewall

Gotchas

  • WebSockets need sticky routing. If your load balancer round-robins, you'll lose connections constantly. Use connection-aware routing (Envoy supports this).
  • Use SSE when the data flow is one-way. It's simpler than WebSockets and has none of the proxy issues.
  • Long-polling is the lowest common denominator. Slack still uses it as a fallback for restrictive networks.
Interview angle

Real-time communication questions test whether you can pick the right protocol for the direction of data flow. For bidirectional chat you want WebSockets, for server-push notifications you should say SSE (simpler, no proxy issues), and for maximum compatibility you fall back to long-polling. The gotcha to proactively mention is that WebSockets need sticky load balancing: a round-robin load balancer drops connections constantly. Candidates lose points by defaulting to WebSockets for everything without discussing connection management at scale.

Your notes

Private to you