'We want real time.' The line shows up in nearly every brief. It sounds modern, it reassures, and most of the time nobody has ever put a number on it. Real time is not a checkbox, it is an architecture decision that commits your budget, your infrastructure and the reliability of your product for years. Let us look at what a real-time application really costs, and when it is worth it.
Real time, in plain terms
A classic application works by requests: the browser asks, the server answers, then the link closes. For fresh information, you have to ask again. Real time flips that logic: the server pushes data to the screen as soon as it changes, with no refresh from the user. The most common technique is called the websocket, a channel kept open at all times between the device and the server. It is what makes a message, a vote or a position on a map appear for everyone at the same instant. That real-time synchronisation is a real comfort, and it is also where the costs begin.
The myth of instant live
Instant is a marketing word, not a physical reality. Between two devices, data crosses cables, routers, sometimes a continent. That latency, that irreducible delay, is measured in tens of milliseconds at best. Add the server processing time and the message queue at peak hours, and 'live' becomes 'almost live'. For a chat or a dashboard, nobody notices. For trading or competitive gaming, those milliseconds are expensive and reshape the whole design. So the first question is not 'can we do real time', but 'what delay is acceptable for this use'.
What real time really costs
Keeping an open channel for every user has very concrete consequences.
- Scaling. A thousand users means a thousand connections open at once, kept alive even when nothing happens. An ordinary web server handles that badly; you need infrastructure built for it, and it has a price.
- Queues. When one event hits everyone at once, messages pile up. Without throttling, the real-time synchronisation falls behind, then drops out.
- Recovery. A connection drops, the mobile network weakens, the tab goes to sleep. The real work is resyncing cleanly, with no duplicate and no lost data.
- Observability. Debugging a permanent stream is harder than a single request. You need tools to see what flows and to understand an incident after the fact.
This is exactly the kind of groundwork we handle in our platforms and infrastructure: a real-time channel is only solid if the layer beneath it is solid too.
When a refresh is enough
The good news is that most products do not need true real time. A dashboard that updates every ten seconds gives an impression of freshness without the cost of a websocket. This is called polling: the application asks again at a regular interval. It is simple, predictable, easy to host and to debug. Reserving real time for the moments where it adds real value, and settling for a refresh elsewhere, is often the most mature decision on a project.
Two needs, two choices
On the Zou. app, a group votes in real time to pick a night out: everyone sees the others' choices move live, and that is the whole point of the product, so the permanent channel is fully justified. On RackSitter, which monitors servers, a regular refresh of the indicators is plenty: nobody loses track of a machine because the reading is five seconds old. Two needs, two answers, and in both cases a deliberate choice rather than a reflex.
Real time is neither a gadget nor a given: it is a dial to set according to use, with a cost you had better know before committing. Set well, it makes a product feel alive; set badly, it undermines everything else. If you are unsure of the right level for your project, let us talk.