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.

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:WhatsApp Chat Dropbox

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.

Your notes

Private to you