Batch vs Stream Processing

Data eventually needs to be processed — aggregated, transformed, analyzed — and there are two fundamentally different ways to schedule that processing: gather it up and process it in large chunks on a schedule, or process each record continuously as it arrives. The choice shapes how fresh the results are, how much infrastructure is needed, and how the system behaves under a burst of data.

Batch: process in large, scheduled chunks

Batch processing collects data over a period (an hour, a day) and processes it all at once, typically on a fixed schedule — a nightly job that aggregates the day's orders into a sales report, for instance. It's conceptually simple: run the same well-tested logic over a large, complete, bounded dataset, and don't worry about partial or incremental state, because every run starts from a known, complete input.

System Design Lab

Stream: process continuously, as it arrives

Stream processing handles each record (or small micro-batch of records) as it arrives, continuously, so results stay up to date within seconds rather than waiting for the next scheduled run. This is exactly the shape of processing Change Data Capture and Message Queues enable: a continuous flow of events, each handled as soon as it shows up rather than accumulated and processed later. A live fraud-detection system checking each transaction as it happens, or a real-time dashboard of current active users, are both stream processing because the freshness of the result is the entire point.

The core tradeoff: freshness vs. simplicity and efficiency

Stream processing's freshness comes at a real cost: it's a fundamentally harder engineering problem than batch, because logic has to handle data arriving continuously, out of order, and incompletely — a batch job can assume "I have all of today's data," while a stream processor never gets that guarantee and has to produce a reasonable answer from whatever's arrived so far. Batch processing, in exchange for giving up freshness, gets to operate on complete, bounded data with much simpler correctness reasoning, and it can be considerably more resource-efficient — processing a day's data in one large, optimized pass is often cheaper in aggregate compute than continuously running infrastructure to handle the same volume as a stream, even though the total data processed is identical.

The question that actually decides it: how fresh does the answer need to be?

This is the practical filter: if a result being a few hours (or a day) stale is genuinely fine — a monthly billing summary, a daily analytics report — batch is simpler, cheaper, and easier to get right, and reaching for streaming infrastructure to shave the staleness down to seconds is solving a freshness problem nobody asked for. If the result needs to reflect reality within seconds — fraud detection, live inventory counts, a real-time leaderboard — batch's inherent lag makes it structurally unable to meet the requirement, no matter how the job is tuned or scheduled more frequently.

Why this matters in an interview

Naming the actual freshness requirement first — not defaulting to "we'll use a stream processor because it's more modern" — is what makes this tradeoff legible. A design that needs daily aggregate numbers and reaches for real-time streaming infrastructure is over-engineering; a design that needs to detect fraud within seconds and proposes a nightly batch job has misunderstood the requirement entirely. State the freshness need, then let it dictate the architecture.