Batch vs stream processing

Why it matters

Daily revenue reports, fraud scores, recommendation models, search indexes, usage-based billing: every data-heavy product computes over more data than one request can touch. The first architectural decision is whether to compute in batches on a schedule or continuously as events arrive. It sets the freshness users see, the cost of the infrastructure, and how hard it is to get correct answers when data arrives late or twice. Interviewers use it to check whether you can reason about latency and correctness together.

The idea

Batch processing runs a job over a bounded dataset: yesterday's logs, last hour's orders. The input is complete when the job starts, so the job can sort, join and aggregate everything, and rerunning it gives the same answer. Stream processing runs continuously over an unbounded sequence of events, updating results incrementally as each event arrives, so answers are fresh within seconds but are computed over data that is never complete.

	Batch	Stream
Input	Bounded, complete at start	Unbounded, never complete
Latency	Minutes to hours (schedule plus run time)	Milliseconds to seconds
Correctness	Easy: full data, deterministic reruns	Hard: late and out-of-order events, state, exactly-once
Cost profile	Bursty compute; cheap when idle	Always-on cluster and state storage
Recovery	Rerun the job	Checkpoints and replay from the log
Fits	Reports, model training, backfills, large joins, reconciliation	Alerts, fraud, live dashboards, personalisation, feeding search and caches
Tools	Spark, Hive, dbt on a warehouse, MapReduce historically	Flink, Kafka Streams, Spark Structured Streaming, Beam

Time is the hard part of streaming

Every event has an event time (when it happened, on the device) and a processing time (when the stream processor sees it). A phone offline in a tunnel delivers events minutes late; network retries reorder them. Aggregating by processing time is easy and wrong ("sales per minute" shifts sales into the wrong minute); aggregating by event time is right but requires deciding when a window is complete. Windows group events (tumbling five-minute windows, sliding windows, session windows separated by inactivity), and watermarks are the processor's estimate that all events up to time T have arrived, letting it close windows. Late data after the watermark is dropped, sent to a side output, or used to update and re-emit the window. The Streaming engines lesson details these mechanics.

Micro-batching

Between the two lies micro-batch: process small batches every few seconds (Spark Structured Streaming's default mode). It gives most of batch's simplicity and throughput with latency of seconds, at the cost of the per-event latency true streaming achieves. For many dashboards and pipelines, seconds is plenty.

Batch as a special case of streaming

A bounded dataset is a stream that ends. Modern engines (Flink, Beam, Spark) run the same program in either mode, and architectures increasingly keep one streaming pipeline and replay the event log to recompute history instead of maintaining a separate batch path; the Lambda and Kappa lessons compare those approaches. Batch remains the right tool for very large joins and model training over months of data, for reconciliation jobs that check streaming results, and where hourly freshness is genuinely enough.

Trade-offs

Batch buys simplicity, completeness, cheap reruns and cost efficiency at the price of staleness. Streaming buys freshness and continuous reaction at the price of state management, time semantics, always-on infrastructure and harder correctness. The choice follows the freshness the product needs: if the answer is "by tomorrow morning", batch; if it is "before the transaction completes", streaming.

In an interview

Choose by freshness and say the time semantics: "Fraud scoring is a stream: card events from Kafka into Flink, five-minute event-time windows per card with a 30-second watermark, results within a second. The finance revenue report is a nightly batch over the warehouse, which also reconciles the streaming totals. Both read the same event log, so we can replay to recompute after a bug." Mentioning event time and reconciliation shows you know where streaming goes wrong.