Polling, long polling, SSE and WebSockets

The problem

HTTP is request and response: the client asks. How does the server tell a browser something now?

The four options

Technique	How	Good	Weak
Short polling	Client asks every N seconds	Trivial, works everywhere	Wasteful, delayed by N
Long polling	Client asks; the server holds the request until there is news (or a timeout), then the client asks again	Near real time, plain HTTP	A held request per client, awkward at scale
Server-sent events (SSE)	One long HTTP response streams events	Simple, auto-reconnect, text over HTTP	One-way only
WebSockets	HTTP upgrades to a two-way connection	Low latency both ways	Stateful connections, more infrastructure

100%

Figure SDA-CORE-08-1 · The four options · © forcsguy.com

Choosing

• Updates are rare or delays are fine: polling.
• The server pushes, the client mostly listens (feeds, scores, notifications, progress): SSE.
• Both sides send often (chat, games, collaborative editing): WebSockets.

Running persistent connections

Connections are long-lived, so capacity is about how many connections a server can hold, not requests per second.

• Put connection handling in servers that are separate from your stateless API.
• Use heartbeats to detect dead connections, and reconnect with backoff and jitter.
• Track which server holds which user so messages can be routed (a presence or session store), and use a pub/sub system between servers.
• When a client reconnects, let it ask for what it missed (events after id X), because connections drop.
• Authenticate on connect and again when tokens expire.

More on this site