When do you actually need real-time — and when does polling quietly win?

“We need it to be real-time” is one of the most expensive sentences in a kickoff meeting. It sounds like a requirement. Usually it is a feeling — the sense that data on a screen should be fresh — wearing the costume of an architecture decision.

The distinction matters because real-time is not a feature you add. It is a posture the whole system has to hold: persistent connections, reconnection logic, presence and fan-out, back-pressure when a slow client can’t keep up, and an operational story for what happens at 2 a.m. when the connection layer degrades. None of that is free, and most of it never appears in the demo.

So before committing, it is worth asking a narrower question than “should this be real-time?” The useful question is: what is the cost of the data being a few seconds stale?

Three honest tiers

Most features fall into one of three tiers. Naming the tier first saves a great deal of money.

Tier 1 — Stale is fine (polling wins). A dashboard that refreshes every 30 seconds. A notifications badge. An order status that updates “soon.” If a human would not notice — or would not act differently — given a 5–30 second delay, you do not need a socket. A plain GET on an interval, cached at the edge, is cheaper to build, trivial to operate, and survives network blips without reconnection code. This is the senior default, and it is unglamorous on purpose.

Tier 2 — Seconds matter (WebSockets earn it). Collaborative editing, live chat, a trading or bidding view, an operations console where an operator acts on what they see. Here, a 20-second delay changes behaviour or breaks trust. A persistent channel (WebSocket, or Server-Sent Events for one-directional streams) is justified — but you are now signing up for connection lifecycle, presence, and fan-out as first-class concerns, not afterthoughts.

Tier 3 — Sub-second, media, or many-to-many (WebRTC territory). Live audio/video, screen sharing, hardware-style telemetry, anything where the latency budget is measured in milliseconds and you are moving media, not JSON. This is the most demanding tier, and the one most often invoked without need. When it is the requirement, it is unforgiving — and it rewards teams who have done it before.

The architecture question is rarely “real-time or not.” It is “which tier, and can we defend that choice in writing six months from now?”

The questions that decide the tier

A few questions move a feature between tiers faster than any amount of debate:

• Who reacts to the update, and how fast? A machine reconciling state tolerates seconds. A human deciding to intervene may not. If no one acts on the freshness, it is decoration.
• How many clients see the same stream? One viewer is easy at any tier. Hundreds of concurrent viewers of the same live stream is a fan-out problem that quietly dominates the design.
• Is it data or media? JSON over a socket and video over a peer connection are different engineering disciplines with different failure modes. Conflating them in planning is where budgets go to die.
• What happens when the connection drops? If the answer is “the user refreshes and it’s fine,” you are likely in Tier 1. If the answer is “we lose the session,” you have a Tier 2/3 reliability problem to design for from day one.

What Tier 3 actually costs — a real example

We built a browser-native proctoring platform for a government assessment programme: many candidates streaming webcam and screen to live supervisors, with audit-grade recording, no desktop client allowed. That is squarely Tier 3 — sub-second, media, many-to-many — and it was the right call, because a supervisor reviewing a recording after an exam cannot intervene during it.

The cost showed up exactly where Tier 3 always charges it: WebRTC peer connections with WebSocket signalling for low-latency monitoring; browser-side recording in resumable chunks so a dropped segment reconciles on the server instead of losing the session; an operator console that lets one person credibly oversee dozens of live tiles. None of that would have been justified for a Tier 1 status board. All of it was non-negotiable here.

The lesson is not “real-time is hard.” It is that the tier should be chosen deliberately, defended in writing, and matched to a team that has paid the cost before — because the parts that break are the parts that never show up in a demo.

The senior move

Default to the lowest tier that honestly meets the need, and make the jump to the next tier a written decision with a reason attached — not an unexamined “make it live.” Most products need far less real-time than the kickoff meeting assumes. The ones that genuinely need Tier 3 are better served by admitting it early and engineering for the failure modes from the start.