Core Concepts

Polling vs Long Polling vs WebSockets vs SSE

These are the four common ways for a server to get fresh data to a client. Polling asks repeatedly. Long polling asks and waits until there's something to say. Server-Sent Events (SSE) keep one HTTP response open and stream events down it. WebSockets upgrade a connection into a full two-way channel. The choice decides latency, server cost and complexity for anything "live": chat, notifications, dashboards, streaming AI responses.

In simple words

Polling is a child asking "are we there yet?" every minute. Long polling is asking once and the driver answering only when you've arrived. SSE is the driver announcing each town as you pass it. A WebSocket is an open phone call where both sides can talk anytime.

From "keep asking" to "keep an open line": lower latency, but more connection state on the server.

How Each Works

Short polling   client: GET /updates  (every 5 s)  -> usually "nothing new"
                simple; wasteful; latency up to the interval

Long polling    client: GET /updates  -> server holds it open until data or
                timeout (~30 s) -> responds -> client immediately asks again
                near-real-time over plain HTTP; one request per message

SSE             client: GET /stream (Accept: text/event-stream)
                server keeps writing "data: ...\n\n" events on the response
                one-way (server -> client), auto-reconnect, text only

WebSocket       HTTP request with "Upgrade: websocket" -> 101 Switching Protocols
                then a persistent full-duplex TCP channel, frames both ways

Comparison

	Direction	Latency	Server cost	Good for
Short polling	client asks	up to interval	many empty requests	rare updates, simplest setups
Long polling	client asks, server waits	low	held requests + re-requests	fallback when others are blocked
SSE	server → client	low	one open connection	notifications, feeds, LLM token streaming
WebSocket	both ways	lowest	one open connection, stateful	chat, multiplayer, collaborative editing

What Changes in the Design

Persistent connections are state: a server holding 100K open sockets must know which user is on which server. A connection registry (user → gateway server, e.g. in Redis) plus pub/sub routes a message to the right server.
Load balancers must support long-lived connections (and WebSocket upgrades); deploys must drain connections gracefully and clients must reconnect with backoff.
Missed messages: on reconnect, the client sends its last-seen id and the server replays what it missed; the live channel is an optimisation over a durable store.

Key Pointers

Need two-way, low-latency, frequent messages? WebSocket.
Only server → client pushes? SSE: simpler, plain HTTP, built-in reconnect.
Rare updates or constrained environments? Polling is fine and stateless.
Always design reconnect + catch-up; connections drop constantly on mobile.

Follow-up Questions

How do you send a message to a user connected to a different WebSocket server?: Look up which gateway server holds the user's connection in a registry, then publish the message to that server (via a pub/sub channel or direct RPC), which writes it to the socket. If the user is offline, store it and send a push notification.
Why do ChatGPT-style APIs use SSE rather than WebSockets?: The response is a one-way stream of tokens for one request. SSE works over ordinary HTTP (proxies, auth, load balancers) without a stateful bidirectional protocol.