When product teams ask for “real-time,” they usually mean one thing: they want the customer to see an instant, accurate result — a balance, a transaction, a status — the moment it happens. What they rarely ask about — and what most engineering teams don’t say out loud until it’s too late — is everything that has to change underneath to make that possible.
I lead the data engineering work behind a platform that updates customer account data in roughly 0.3 seconds across more than 20 countries. It’s the kind of metric that looks great in a slide deck. It’s also the kind of metric nobody explains the cost of.
The Promise vs. The Reality
“Real-time” sounds like a performance upgrade — the same system, just faster. In practice, it’s a different system entirely. Batch processing and real-time streaming aren’t two speeds of the same architecture; they’re two different sets of engineering trade-offs, and moving from one to the other means giving something up.
Here’s what actually changes.
Trade-off 1: Infrastructure Never Sleeps
A batch pipeline runs on a schedule. It spins up, processes a defined chunk of data, and shuts down. You size it for a known, predictable load, and you pay for compute only when it’s running.
Real-time infrastructure doesn’t get that luxury. To hit sub-second latency, we moved from scheduled batch windows to Kafka-based streaming pipelines running continuously — ingesting, validating, and processing events as they arrive, 24 hours a day, across every region we operate in. That means infrastructure cost stops being a predictable, scheduled expense and becomes a constant, always-on one. You’re not paying for the job. You’re paying for the readiness to run the job at any moment.
Trade-off 2: You Have to Over-Provision for the Worst Moment, Not the Average One
With batch processing, you size your systems for a known nightly volume. With real-time, load doesn’t arrive on a schedule — it spikes unpredictably, driven by real customer behaviour across time zones you don’t control.
That forces a different kind of inefficiency: provisioning capacity for the worst plausible moment, not the average one. Most of the time, that capacity sits underused. It’s the price of not being caught out when 20+ countries’ worth of activity doesn’t arrive politely, one region at a time.
Trade-off 3: Debugging Gets Harder, Not Easier
This is the trade-off nobody warns you about. In a batch system, when something breaks, you can often re-run the job against the same static data and reproduce the bug in a controlled way. It’s slow, but it’s forgiving.
In a real-time streaming system, the data that caused the problem has already moved on by the time you notice something’s wrong. You’re debugging a system in motion, correlating event timestamps across distributed logs, trying to reconstruct a sequence that happened live and won’t happen the same way twice. What used to be a next-morning investigation becomes an active incident, and the tools you’d normally reach for — pause, inspect, re-run — don’t work the same way anymore.
Trade-off 4: The On-Call Burden Changes Shape
Batch failures are, in a strange way, kind. They fail overnight, and someone catches it in the morning before business impact spreads. Real-time failures are immediate and visible — a stalled Kafka consumer or a schema mismatch shows up as a customer-facing problem within minutes, not hours.
That changes what “reliable” means for the team. Monitoring has to be more granular. Alerting has to be tuned carefully enough to catch real problems without drowning the team in noise from a system that’s now always, technically, “live.” And the expectation for response time compresses — from “we’ll look at it this morning” to “someone needs to look at it now.”
So Is Real-Time Worth It?
For a platform where customers expect instant, accurate account data the moment they check it, yes — the trade-offs are worth making deliberately. The mistake isn’t building real-time systems. The mistake is promising “real-time” as if it’s a free upgrade, without the team or the stakeholders understanding what they’ve actually signed up for.
A Short Checklist Before You Promise “Real-Time”
- Cost: Are you budgeting for continuous infrastructure, not scheduled compute?
- Capacity: Are you sizing for peak, unpredictable load — not average load?
- Debugging: Can your team actually reproduce a live-stream bug, or only a batch one?
- On-call: Is your alerting tuned for a system that fails in minutes, not overnight?
- Stakeholder expectations: Does everyone asking for “real-time” understand it’s a different system, not a faster version of the old one?
“Real-time” is a real engineering decision with real costs. The teams that succeed with it are the ones who make that trade-off on purpose — not the ones who discover it after they’ve already promised it.
