Streaming vs batch: is being fast worth the cost?

Batch processing collects data over a window and processes all of it at once, on a schedule — hourly, nightly. Streaming processes each event as it arrives, continuously, with results available near-instantly. The distinction isn't about data volume — it's about whether the VALUE of an insight decays before the next scheduled batch run would deliver it.

Many real systems run both paths deliberately: a fast streaming path gives approximate, real-time results immediately, while a slower batch path recomputes exact, corrected results later and reconciles the two (this is the Lambda architecture). Increasingly, teams instead push everything through the streaming engine and treat "batch" as simply a stream replayed over a bounded window (the Kappa architecture), to avoid maintaining two separate codepaths for the same logic.

It's intuitive to think streaming is just "batch, but faster" — but the actual engineering tax streaming adds comes from a different place: events in the real world arrive out of order, late, or duplicated, because they cross an unreliable network from many independent sources. A completed batch window sidesteps this almost entirely — by the time you process it, the data for that window is already complete and effectively ordered, because you waited for the window to close before touching it.

Streaming has no such luxury: it has to make a decision on data as it arrives, without knowing whether more (older) data is still in flight. This forces explicit concepts batch gets for free — EVENT TIME vs PROCESSING TIME (when something actually happened vs when your system saw it), WATERMARKS (a heuristic for "how late are we willing to wait before assuming no more data is coming for this window"), and delivery semantics (exactly-once vs at-least-once, since a network retry can duplicate an event). None of this is about raw processing speed; it's the cost of making correct decisions on data whose completeness you can't yet verify.

An e-commerce platform computes "customers likely to churn" scores in a nightly batch job over the full order history — being a day stale is completely fine here, and the job benefits from large historical joins that are much simpler to reason about once the day's data is known to be complete and ordered.

The same platform needs streaming for fraud detection on live checkout attempts, where a decision has to be made in the roughly 200ms before a payment authorizes — batch's next scheduled run, even an hour away, would be far too late to stop a fraudulent charge that's happening right now. Notice these aren't different scales of the same problem; they're genuinely different problems, one where waiting costs nothing and one where waiting is the failure.

Latency aside, there is a cost crossover too. Streaming runs always-on; batch pays per run but has to run often to stay fresh. Say a batch run costs C_b and a streaming pipeline costs C_s per hour. To hit a freshness of F hours, batch runs 24/F times a day at (24/F)·C_b, while streaming costs 24·C_s. Setting them equal, the crossover is at F = C_b / C_s hours.