Real-time order tracking: polling, SSE or WebSockets

Kreshnik Rraci · 5 September 2026

The word "real-time" hides three different engineering problems, and the most common mistake in building an order-tracking screen is picking one transport to solve all of them. WebSockets for something that changes six times an hour is the usual result.

The problem: one screen, three streams

Look at what an order-tracking view actually shows, and how each piece changes:

Four update patterns with nothing in common but the screen they land on. The transport that is right for a courier's position is wasteful for a status field and wrong for a chat. Treating them as one requirement means over-engineering three of the four.

The useful reframing: classify each stream by cadence, direction and fan-out, then choose a transport per stream. The transport is an edge concern. What matters underneath is that one state-change event can feed any of them.

The options

Two of these are routinely underrated.

Conditional polling is not the naive option. A GET with If-None-Match that returns 304 Not Modified carries no body, is answered from a cache or a cheap lookup, and keeps every piece of infrastructure stateless. For a value that changes a few times an hour, polling every 30 seconds with an ETag is close to free, and the "latency" of up to 30 seconds is invisible on a status that changes that rarely.

Server-Sent Events do most of what people reach for WebSockets to do. They are plain HTTP: one long-lived response with Content-Type: text/event-stream. The browser reconnects automatically, sends the last event ID it saw so the server can resume, and - over HTTP/2 - the old six-connections-per-host limit that made SSE awkward is gone, because streams are multiplexed on one connection. All of that is built into EventSource; none of it has to be written.

The pattern: one event, a transport per stream

1. Classify first

Every stream on the screen gets three labels before anyone picks a technology:

• Cadence - how often it changes, and for how long.
• Direction - does the client ever send on this channel, or only receive?
• Fan-out - how many clients watch the same stream at once?

Then apply a small rule set:

Applied to the tracking screen: order status → polling; courier position → SSE; the conversation → WebSockets if it's a first-class feature, otherwise it too is polling plus a POST; the arrival alert → push.

2. Decouple the event from the edge

The transports differ at the edge. Underneath, they should all be fed by the same thing: a state-change event emitted once when a fulfilment moves from preparing to shipped, or a courier reports a position.

This is what makes the per-stream choice reversible. If courier tracking moves from SSE to WebSockets because the client starts sending its own position, the domain code doesn't know. If polling for status becomes too chatty at scale, the same event feeds an SSE stream instead. The decision lives at the edge, where it's cheap to revisit.

3. The mechanics that make each one work

Polling that behaves. Send If-None-Match with the last ETag; treat 304 as "no change". Add jitter to the interval so a thousand clients don't align. Back the interval off while nothing changes, and reset it when something does. Pause entirely when the tab is hidden - document.visibilityState - and poll immediately on return. Done well, polling is a small number of nearly-empty requests per client per hour.

SSE that resumes. Give every event an id: and the client will send Last-Event-ID on reconnect, so the server can replay from the log rather than restart. Send a comment line (: ping) every 15-30 seconds to keep proxies from closing an idle response. Disable response buffering at every layer between the process and the client - a buffered SSE stream is one that arrives all at once, late. Make sure the event log is retained long enough to cover a realistic reconnect gap.

WebSockets that survive. Heartbeat both ways with a timeout, because a TCP connection can be dead without either end noticing. Reconnect with exponential backoff and jitter. Decide, early, how a message reaches a client connected to a different server than the one that produced it - the answer is a pub/sub backbone every node subscribes to, and it's what makes the tier stateful. Authenticate on the upgrade request; the socket inherits the session but can't easily renew it.

Push that people don't turn off. Push is for the moment the user isn't looking: arrival, a problem, a required action. It is not a transport for updates; a push per status change is how permission gets revoked. Route "informational while open" through the in-app channels above and reserve push for "actionable while away".

The trade-offs

SSE is one-directional and needs HTTP/2 to be cheap. Over HTTP/1.1 each stream is a whole connection, and browsers cap those per host. Behind a reverse proxy, it needs streaming and buffering handled correctly, which is a configuration item that is easy to get wrong and hard to notice locally.

WebSockets make the tier stateful. Load balancers need sticky sessions or the backbone described above; deploys have to drain connections; autoscaling has to account for long-lived sockets rather than request throughput. This is real operational cost, and it's the reason to use them only where the stream needs both directions.

Polling has a latency floor equal to its interval, and it does not degrade gracefully at very high concurrency - a million clients polling every 30s is 33,000 requests a second of mostly 304s. It is the right default for low-cadence streams and the wrong one for anything with real-time in the product's promise.

Per-stream transports mean per-stream code paths. Three mechanisms on one screen is more surface than one. The mitigation is the shared event underneath: the delivery code is thin because the domain code is the same.

When it flips

• Presence, typing indicators, collaborative state. Anything where the client transmits as often as it receives is a WebSocket, full stop.
• Live courier maps with many concurrent watchers (a dispatcher view, not a single buyer) still suit SSE, but if the same client also streams its own position - a courier app - that channel is bidirectional and moves to WebSockets.
• Auctions, live pricing, anything with sub-second fairness requirements. Polling's latency floor is disqualifying; SSE or WebSockets depending on direction.
• Extremely constrained networks - some corporate and captive-portal proxies break WebSockets outright. SSE, being plain HTTP, survives more of them, and polling survives all of them. A fallback ladder (WS → SSE → polling) is worth it only if those users are your users.

Checklist

1. Have we listed every stream on the screen, with its cadence, direction and fan-out?
2. Is there a stream we're serving over WebSockets that never sends from the client?
3. Does polling use conditional requests, jitter, backoff and visibility pausing?
4. Do SSE events carry an id, and is the log retained long enough to resume?
5. If we use WebSockets, how does a message reach a client on a different server, and what happens on deploy?
6. Is push reserved for things that are actionable while the app is closed?
7. Does one state-change event feed every transport, or does each have its own producer?
8. Can we change the transport for one stream without touching the domain?

The screen looks like one feature. It's three or four, and each one gets the transport it deserves - not the one the most demanding stream needs.