Batch vs. streaming
Hook
A product manager asks for "real-time" analytics. You could spend two weeks standing up a streaming system — or you could run a job every five minutes and be done by lunch. The word "real-time" hid a question nobody answered: how fresh does this data actually need to be? Answer that, and the batch-versus- streaming decision mostly makes itself.
Concept
There are two fundamental ways to move and process data through the lifecycle.
Batch processing collects data into groups — an hour of events, a day of orders — and processes each group as a unit on a schedule. Stream processing handles each record (or a tiny micro-batch of them) as it arrives, continuously, with no natural end.
The intuition: batch is doing the laundry once the hamper is full; streaming is washing each sock the moment you take it off. Precisely: batch operates on bounded datasets with a known size and a defined start and end; streaming operates on an unbounded dataset that, in principle, never ends.
Do not choose by fashion. Choose with three levers.
| Lever | Batch | Streaming |
|---|---|---|
| Latency | Minutes to hours (schedule-bound) | Seconds or less (per-event) |
| Cost | Lower; runs then stops | Higher; always-on infrastructure |
| Correctness | Simpler; reprocess a whole batch | Harder; late and out-of-order events |
Three points deserve emphasis, because they are where teams go wrong.
First, latency is a budget, not a wish. "As fast as possible" is not a requirement. A fraud check may need sub-second latency; a daily finance report is fine at "by 6 a.m." Name the number the business actually needs, and let it pick the tool.
Second, streaming is more expensive, and not only in dollars. Always-on infrastructure costs money whether data is flowing or not, and it costs engineering time: handling late-arriving and out-of-order events correctly is genuinely hard, and getting it wrong produces subtly wrong numbers that are painful to debug.
Third — an opinion the industry mostly agrees on — default to batch, and reach for streaming when a latency budget forces you to. Batch is simpler to build, cheaper to run, and far easier to reason about when it breaks. Most "real-time" requests are satisfied by a batch job running every few minutes. Reserve streaming for cases where seconds genuinely matter: fraud, alerting, live operational dashboards.
A useful middle ground is the micro-batch: process small groups on a tight schedule (say, every 60 seconds). It buys most of streaming's freshness with most of batch's simplicity, which is why it is often the pragmatic answer.
Worked example
Let me make the decision framework concrete with a scenario and a small model
of the cost side. An online store wants two things from its orders stream: a
fraud flag on suspicious orders, and a daily sales summary by category.
Same source data, two very different latency budgets.
- Fraud flag: the budget is sub-second — a flag after the order ships is worthless. This one earns streaming.
- Daily summary: the budget is by tomorrow morning. This is batch.
To show why the summary should not be streamed, here is a back-of-the-envelope comparison of processing the same day of orders both ways:
orders_per_day = 500_000
# Batch: one scheduled run that then stops.
batch_run_minutes = 6
batch_cost_per_minute = 0.05
batch_daily_cost = batch_run_minutes * batch_cost_per_minute
# Streaming: an always-on service, billed for all 1440 minutes/day.
stream_cost_per_minute = 0.04
stream_daily_cost = 1440 * stream_cost_per_minute
print(f"Batch: ${batch_daily_cost:.2f}/day for {orders_per_day:,} orders")
print(f"Streaming: ${stream_daily_cost:.2f}/day for the same orders")
Batch: $0.30/day for 500,000 orders
Streaming: $57.60/day for the same orders
The streaming version costs roughly 190 times more to produce a number nobody reads until morning — and that is before the extra engineering time to handle late and out-of-order events. The lesson is not "streaming is bad." It is that you spend streaming's cost only where a latency budget demands it, like the fraud flag. Match each need to its budget, and the same source feeds a streaming path and a batch path without waste.
Hands-on
Your turn, with three fresh scenarios. The exercise below gives you three business requirements — each with a stated latency need, data volume, and cost sensitivity — and asks you to classify each as batch, streaming, or micro-batch, then justify the call in a short structured answer.
Success criteria: each scenario is classified correctly and your justification names the deciding latency budget. Python Arena checks your classifications against the rubric automatically.
Recap
- You can define batch as processing bounded groups on a schedule and streaming as processing an unbounded flow continuously.
- You can choose between them using three levers: latency budget, cost, and correctness difficulty.
- You can explain why batch is the sensible default and when a latency budget justifies the cost of streaming.
Next up, in the lab, you will pull all three lessons together: sketch a full pipeline, place its lifecycle stages, and mark where a batch-versus-streaming decision belongs.
- Batch processes bounded groups on a schedule; streaming processes an unbounded flow. - Decide with three levers: latency budget, cost, and correctness difficulty. - Default to batch; reach for streaming only when a latency budget demands it.