Grokking the System Design Interview

0% completed

Batch Processing vs Stream Processing

On This Page

Two Ways to Process Data

Batch Processing

Batching Writes in Real-Time Systems

Stream Processing

Windows

Late Events

Delivery Guarantees

Batch vs. Stream

Using Both

Choosing Between Them

Using This in an Interview

Key Takeaways

Practice Questions

A payroll system calculates salaries once a month. A fraud detection system must decide whether a card payment looks suspicious before the payment completes, in a fraction of a second.

Both systems process data. But they need the answer at very different times, and that changes how each system is built.

This lesson compares batch processing and stream processing, explains the new problems that streaming brings, and shows how to choose between them.

Two Ways to Process Data

Batch processing collects data over a period of time, and processes it all together, on a schedule.
Stream processing handles each record as it arrives, and never stops.

The choice is not about which approach is more modern. It depends on one question: how stale can the answer be? A stale answer is one built from old data. Batch answers are usually hours old. Stream answers are usually seconds old, and that freshness costs more.

Batch processing collects records and runs a job on a schedule, while stream processing handles each record as it arrives

Batch Processing

In batch processing, data collects in a storage system, like a data lake or a data warehouse. Then a job runs over the whole collection on a schedule, for example every hour, every night, or every month.

The input is bounded, which means it has a clear start and end. The job sees a complete set of records, and that gives it real advantages:

It can see all the data at once. It can sort the full dataset, join two very large tables, and read the same records several times.
Failures are easy to recover from. If a nightly job crashes halfway, the team fixes the bug and runs it again on the same input. If the job is written to be repeatable, the result is the same.
It is cheap and simple. The work runs in bursts, often on low-cost spare capacity, and nothing runs between jobs.

Common tools: Apache Spark, Hadoop MapReduce, and schedulers like Apache Airflow.

Good fits: payroll, monthly billing, nightly reports, loading a data warehouse, retraining a machine learning model, and backfills, which means processing historical data again.

The cost is freshness. The answer is only as fresh as the last run. If the job runs at 2 AM, a question asked at 3 PM is answered with data that is about 13 hours old.

Batching Writes in Real-Time Systems

Batching is not only for nightly jobs. Write-heavy systems also group small writes together, which is called write batching or buffering. This reduces the overhead on the database, because many rows share one database call.

For example, suppose writing one row per database call takes 2 ms. That gives at most 500 rows per second. If the service writes 500 rows in one call that takes 50 ms, it can write up to 10,000 rows per second. Throughput rises. But each row waits longer until its batch is full. Very large batches make this waiting even longer. The Latency vs Throughput lesson explains this trade in detail.

Stream Processing

In stream processing, records are processed as they arrive, one at a time or in very small groups. The input is unbounded, which means it never ends. So the job runs all the time, and the answer is only seconds behind.

Detecting fraudulent card payments in real time is a classic example. The system must check each payment as it happens. An answer that arrives tomorrow, after a nightly batch job, would be useless.

The hard part of streaming is that the system never holds the complete dataset. It works with an endless sequence of records, and it must decide how much to keep in memory. This creates three ideas that batch processing does not need.

Windows

The stream never ends, so a count needs a boundary. A window is that boundary, like "purchases in the last five minutes". There are three common kinds:

Fixed windows, also called tumbling windows: each five-minute block is counted separately.
Sliding windows: the last five minutes, updated every minute.
Session windows: one user's activity, grouped together until the user is inactive for some time.

A stream never ends, so counts use fixed, sliding, or session windows

Late Events

A customer makes a purchase on a phone at 10:02. The phone loses its signal in a tunnel, and uploads the event at 10:12. But the window from 10:00 to 10:05 has already closed, and its count was already reported.

There are three options, and each one has a cost:

Drop the late event. This is simple, but the count is slightly wrong.
Wait longer before closing windows, using a watermark. A watermark is a rule for how long the system waits for late records before it closes a window. Results are more complete, but they arrive later.
Close the window on time, and send a correction later. Results are fast, but the systems that read them must handle updates.

An event from 10:02 arrives at 10:12, after its window closed, so the system must drop it, wait longer, or send a correction

Delivery Guarantees

Suppose a processing server crashes in the middle of handling a record. Was that record processed or not?

Most systems promise at-least-once delivery, so a record may be processed more than once. The processing logic must then be idempotent, which means processing a record twice has the same effect as processing it once. Some tools, like Apache Flink and Kafka Streams, offer exactly-once processing, but it costs more and must be configured on purpose.

Common tools: Apache Flink, Kafka Streams, and Spark Structured Streaming.

Good fits: fraud detection, live dashboards, alerts, and anything where a late answer is as bad as no answer.

The costs: more components to run, harder debugging, and a system that must stay up all the time. A failed batch job can often run again tomorrow. A failed stream job is an incident right now.

Batch vs. Stream

	Batch	Stream
Input	Bounded, a complete set	Unbounded, never ends
Runs	On a schedule	All the time
Freshness	Hours old	Seconds old
Cost per record	Lower, work runs in bursts	Higher, infrastructure always running
A failure is	A job to run again	An incident now
Processing history again	Easy, run the job on old data	Harder, needs a replay or a second path
Complexity	Lower	Higher: windows, late events, and delivery guarantees

Two rows need a closer look.

Cost per record. Batch is usually cheaper for the same amount of data, because streaming infrastructure keeps running even when little data arrives. If nobody needs the answer sooner, paying for streaming gives no benefit.

Processing history again. Business rules change. Sooner or later, someone asks the team to recalculate the last two years of data under the new rules. Batch does this naturally. A pure streaming system needs a stored log of past events that it can replay, or a separate batch path.

Using Both

Many companies run both on the same data.

In a Lambda architecture, a streaming path produces fast, approximate numbers for dashboards and alerts. A nightly batch path calculates the same numbers exactly, and replaces them. The cost is that the team maintains the same logic twice.
In a Kappa architecture, there is only a streaming path. To process history again, the team replays a stored event log through a new version of the job. This works only if the log, often Kafka, keeps events for as long as they might be needed.

Lambda runs a fast stream path and an exact batch path on the same events, while Kappa keeps one stream path and replays the log

Choosing Between Them

Ask the same question again: how stale can this answer be before it stops being useful?

A day is fine: use batch. It is cheaper and simpler, and simpler systems break less often.
The answer is useless after a few seconds: use streaming. Fraud checks, alerts, and live pricing cannot wait.
A few minutes is fine: consider micro-batching, which means running small batch jobs every few minutes. It is often fresh enough, with much less infrastructure.
History will need to be recalculated: keep a batch path, or an event log that can be replayed.

Using This in an Interview

Do not choose streaming just because it sounds impressive. Interviewers notice when a design adds Kafka and Flink for users who would not notice a nightly update. First state how fresh the data must be, and then choose.

If you choose streaming, expect follow-up questions about windows and late events, because that is where the real design work is. A concrete answer helps. For example: "Five-minute fixed windows, a two-minute watermark, and events that arrive later go to a correction stream."

Key Takeaways

Batch processing handles a bounded set of data on a schedule. It is cheap, simple, and easy to run again, but its answers are hours old.
Stream processing handles an unbounded flow of records all the time. Its answers are seconds old, which makes it right for cases like real-time fraud detection.
Streaming brings new problems: windows, late events, and delivery guarantees.
Batching writes raises throughput and reduces database overhead, but each item waits longer while its batch fills.
Decide by asking how stale the answer can be, and state the number.
Large systems often run both, with a fast streaming path and an exact batch path, or a replayable event log.

Batch and stream processing trade freshness against cost and complexity. The next lesson, SQL vs. NoSQL, moves to a different decision: how to store the data in the first place.

Practice Questions

Try each question first, then open the answer.

1. A report job runs every night at 2 AM, using all data collected until then. A manager opens the report at 3 PM. How old is the newest data in the report?