The Real-Time Problem

Why is real-time hard?

HTTP was designed as a request–response protocol: the client asks, the server answers, the connection closes. But many features need the server to tell the client something happened — a new chat message, a stock tick, a notification, a build-finished event. The server has no standing channel to reach a client that is not actively asking.

There are four mainstream techniques, in increasing order of immediacy and complexity:

• Short polling — the client repeatedly asks every N seconds.
• Long polling — the client asks, the server holds the request open until it has data.
• Server-Sent Events (SSE) — one long-lived HTTP response that streams events server→client.
• WebSockets — a persistent, full-duplex TCP connection for two-way messaging.

Choosing among them is a classic interview trade-off question. The right answer is almost never one size fits all — it depends on direction (one-way vs two-way), latency tolerance, message frequency, and operational complexity.