System Design ยท medium
Batch vs streaming: how do you decide for a given use case?
Asked in Data Engineer interviews, in the System Design round.
Short answer
Latency needs, cost, complexity, data freshness SLAs, and correctness guarantees.
| Batch | Streaming | |
|---|---|---|
| Freshness | Minutes to a day | Seconds |
| Cost per event | Low | Higher, always-on infrastructure |
| Reprocessing history | Rerun the job | Replay the log, harder |
| Late data | The next run picks it up | Needs watermarks and windows |
| Operational load | A failed run is a rerun | On-call for an always-running consumer |
| Choose it when | A dashboard or a daily model | Fraud, alerting, live personalisation |
How to answer it
The decision
Start from the decision latency the business actually needs, not from the technology. The table above compares the two; what follows is how to choose between them without guessing.
The questions that decide it
- What action is taken on this data, and how quickly must it happen? Blocking a fraudulent transaction is seconds. A weekly board report is not.
- What does one hour of staleness cost? If the answer is nothing, batch.
- Who is on call, and does the team have the operational maturity for an always-running consumer?
- How often will history need reprocessing? Batch reruns; streaming replays, which is harder.
Cost
Batch compute in bursts, idle between runs, cheap
one failure = one rerun
Streaming always-on infrastructure, always-on cost
a failure at 3am is an on-call page
plus watermarks, windows and late-arrival handling
Streaming is not just more infrastructure; it is more concepts the team has to hold. That is the cost people underestimate.
The middle ground
Micro-batching every five or fifteen minutes covers a surprising share of "real-time" requests at batch-like cost and complexity. When someone asks for real time, ask what they will do with it: often a fifteen-minute refresh is indistinguishable to them and an order of magnitude cheaper.
Key points
- Decide from the decision latency, not from the technology.
- Streaming costs more in infrastructure and in concepts: watermarks, windows, late data.
- Reprocessing history is straightforward in batch and genuinely hard in streaming.
- Micro-batching often satisfies a real-time request at batch cost.
- Many systems are both: streaming for the live path, batch for the correct daily restatement.
FAQ
- What is the lambda architecture? Running both, with the batch layer as the source of truth and the streaming layer for freshness. Powerful and expensive to maintain.
- Can streaming be exactly once? End to end, at a cost. At least once with idempotent consumers is usually the better trade.
- Does the warehouse change the answer? Somewhat. Modern warehouses make frequent micro-batches cheap, which narrows the gap.
The 30-second answer
I would start from the decision rather than the technology: what action gets taken on this data, and how quickly does it have to happen. Blocking a fraudulent payment is seconds, so that is streaming. A weekly report is not, so that is batch.
Then I would ask what an hour of staleness actually costs. If the answer is nothing, batch, because it is cheaper, a failure is just a rerun, and reprocessing history is straightforward, which in streaming it really is not.
The option I would raise explicitly is micro-batching every ten or fifteen minutes, because when someone asks for real time that is very often indistinguishable to them and an order of magnitude cheaper. Streaming costs more than infrastructure: watermarks, windowing and late arrivals are concepts the whole team then carries.
In the interview
- What they are checking: that you decide from the consumer's latency need and name the operational cost of streaming.
- Common mistake: "streaming is more modern". It is more expensive, and most data has no one waiting for it.