The Cost of Making Everything Real Time
Real time sounds like an obvious improvement until you price it. The useful question is not how fast the data can arrive, it is how often anyone actually acts on it.
Someone asks for the data to be real time. It sounds like a small request, the kind you’d feel unreasonable pushing back on. Of course people want current numbers. Nobody stands up in a meeting and argues for stale data.
So the requirement goes in, and it feels free. It isn’t. “Real time data” is three friendly words with a lot of cost hidden behind them, and most of that cost has nothing to do with whether the data is useful.
“Real time” isn’t a specification
When someone says they want something in real time, they almost never mean the engineering definition. They rarely mean sub-second, always-current, never-stale. What they usually mean is “fresh enough that I can trust it when I look.”
That’s a different request, and it’s a much cheaper one. But it stays hidden as long as the conversation is about speed instead of about the decision the data supports. The first useful move is to stop treating “real time” as a target and start treating it as a symptom of a question nobody has asked yet: what are you going to do with this, and how soon does acting actually matter?
Until that question is answered, you’re buying speed you can’t price.
The cost lives between real time and near time
There’s a wide gap between near time and real time, and it’s where most of the money goes.
Near time is refreshing on a schedule that keeps pace with how people work: every few minutes, every hour, whatever matches the rhythm of the decision. Real time is a live pipe. It’s a system that has to react the moment a source changes, hold that state, and keep it correct while everything else is also changing. The step from one to the other doesn’t cost a little more. It costs disproportionately more, for a gain that often nobody notices.
This gets sharper the more sources you have. A product that pulls together data from a lot of separate places, each one changing on its own schedule and none of them coordinating with the others, is doing constant reconciliation work just to present a single coherent view. Keeping that view merely fresh is real engineering. Keeping it live, across every source, all the time, is a standing cost that shows up in infrastructure, in on-call, and in the pipelines you now have to keep healthy forever. The work never fully stops, because the requirement is that nothing is ever allowed to be behind.
You pay that bill every day, whether or not anyone opens the page.
Most people look back less than they think
Here’s the part that gets skipped. Before you commit to a freshness target, it’s worth knowing how people actually use the thing.
The gap between what people say they need and what they do is usually large. Someone insists a report has to be live, and then the logs show they open it once on a Monday and skim last week. A team asks for a real-time feed and then makes the same decision on a weekly cadence, because that’s when the meeting is, or when the order goes in, or when anyone can actually act. The data was never the constraint. The decision was, and the decision moves slowly.
None of this means people are wrong to want current data. It means the stated need and the real one have drifted apart, and building to the stated one is how you end up paying for real time to serve a weekly habit.
Measure what people actually do
This is where product analytics earns its place. Before you spend anything on freshness, instrument how the data is used. Tools like Google Analytics or PostHog exist for exactly this, and the questions they answer are the ones that should set the target.
How often is this actually viewed? How far back do people look when they open it? Does anyone return within the window that real time would serve, or is the second visit always days later? Which numbers get acted on quickly, and which just get glanced at for reassurance?
Do that for a couple of weeks and the freshness target usually chooses itself. You stop guessing at what people need and start reading what they do. In most cases the honest answer is near time, and the data now says so out loud, which makes it a much easier conversation than an opinion against an opinion. This is the same instinct as good observability: don’t assume what matters, watch what actually happens.
Match freshness to the decision, not the data
The target should track the decision, not the source. Data can change every second, but if the person acts on it once a day, once-a-day freshness is correct, and anything faster is spending for a feeling.
So set freshness per decision, not once for the whole product. A live operational alert and a monthly trend both count as “the data,” and they don’t need the same guarantees. Give each one a target that matches how fast someone acts on it. Some of it will genuinely need to be quick. Most of it won’t, and pretending otherwise is how a product ends up carrying real-time cost across the board to serve a handful of decisions that actually needed it.
Matching the cadence isn’t the cheap answer for its own sake. It’s the honest one. It puts the speed where acting sooner is worth something and takes it away from everywhere it isn’t.
The question worth asking first
Next time real time goes on a spec, ask one thing before anyone builds it: what decision changes if this number is fresher?
If someone can name the decision, the action, and how soon it has to happen, you have a real requirement and a target falls out of it. If the answer is that it would just be nice to see, or that current data feels better, then you’ve found something worth knowing before you pay for it. Nice to see is a real thing, but it’s rarely worth a live pipe across every source.
Fresh enough to act on is the goal. Real time is one way to get there, and usually the most expensive one.