Why Real-Time Is Hard

Documents Versus Live Data

HTTP’s request-response model was designed for documents: a client asks for a resource, and a server returns it.

Each exchange has a clear end. That works well when a page changes only after someone requests a new version.

Live data follows a different rhythm. Users expect updates as events happen, even when they have sent no new request.

The Stateless Foundation

Stateless HTTP treats each request as a separate exchange. The server handles the request, returns a response, and does not require an ongoing conversation.

That simplicity suits document retrieval. A client can ask for a page, receive it, and finish.

Real-time systems need continuity because new information may appear between requests.

Where Latency Appears

Latency is the delay between an event and the moment a user sees its update.

With ordinary HTTP, the client must send a request before receiving fresh data. The event can happen first, leaving the user waiting for the next exchange.

Even a short delay becomes noticeable when information changes frequently.

Polling Repeats Requests

Polling means asking the server for updates repeatedly. The client sends requests at chosen intervals, whether or not new data exists.

Frequent polling can reduce waiting, but it creates extra request-response exchanges. Many requests may return nothing new.

Infrequent polling reduces overhead, yet users may wait longer for changes. This creates a basic trade-off.

The Server Needs A Voice

Real-time updates often require the server to send information when an event occurs.

The usual HTTP pattern gives the client the first move: request, then response. A server-initiated update reverses that timing by delivering new information without a fresh client request.

The illustration makes the timing reversal visible: an event at the server can send an update without a fresh client request.

This difference is central to the challenge of building live experiences.

Choosing The Right Model

The mismatch becomes clear: documents fit a finished exchange, while live data keeps changing.

Latency delays updates. Polling can create unnecessary traffic. Stateless HTTP does not preserve an ongoing exchange for spontaneous updates.

When designing a real-time feature, ask how quickly data must appear, how often it changes, and whether the server needs to initiate updates.

Why live experiences need a different rhythm

HTTP’s request-response model was primarily designed for which use?

• Retrieving documents
• Streaming spontaneous events

Answer: Retrieving documents

HTTP’s request-response model was designed for documents: the client requests a resource, and the server returns a completed response. Live data may change without a new client request.

Complete using: latency; polling. The delay between an event and a visible update is _____. Repeatedly asking the server for updates is _____.

Answer: Complete using: latency; polling. The delay between an event and a visible update is latency. Repeatedly asking the server for updates is polling.

Latency is the delay between an event and the user seeing its update. Polling is the repeated asking for updates, even when no new data exists.

Why does polling create a trade-off in a real-time system?

• It reduces waiting but can create unnecessary traffic.
• It eliminates requests that return no new data.
• It lets the server send updates without client requests.

Answer: It reduces waiting but can create unnecessary traffic.

Frequent polling can make updates appear sooner, but it creates more request-response exchanges, including requests that return nothing new. Infrequent polling reduces overhead but can increase waiting time.