Batch versus streaming is one of the first design decisions that shows up on the Professional Cloud Architect exam, and the question is rarely about syntax. It's about what shape the data has when it arrives and how soon someone needs an answer.
Batch processing means data is collected first and processed in large chunks. The chunks can be triggered on a schedule (hourly, daily, weekly), when a threshold is hit (a file lands in a Cloud Storage bucket, a row count crosses a limit), or manually by an operator. The defining property is that the input is finite and known before processing starts, which is why batch data is also called bounded data.
Typical batch workloads on Google Cloud include monthly customer billing runs, end-of-day financial reporting, and inventory reconciliation. None of these need to react in seconds. They need to chew through a defined dataset accurately. A nightly Dataflow job reading from Cloud Storage and writing aggregates to BigQuery is a textbook batch pipeline.
Streaming processing handles data continuously as it arrives, in real-time or near real-time. There is no waiting for a chunk to fill up. Each event is processed soon after it lands. The input has no defined end, which is why streaming data is called unbounded.
The use cases follow the latency requirement. Fraud detection has to flag a suspicious transaction before the payment clears. IoT fleets push sensor readings every few seconds and the platform has to keep up. System monitoring pipelines need to surface a failing service immediately, not in tomorrow's report. On Google Cloud, the canonical streaming stack is Pub/Sub for ingestion, Dataflow for stateful processing, and BigQuery or Bigtable for the sink.
Batch is efficient at moving large volumes of data because the system can optimize across the whole dataset. Sort, shuffle, aggregate, and write once. The cost is latency. Insights arrive only after the chunk is collected and processed, so a daily batch means up to 24 hours of delay between an event happening and showing up in a report.
Streaming flips both sides. Latency drops to seconds or less, which enables real-time decisions. The cost is infrastructure. Streaming pipelines run continuously, hold state across events, handle late and out-of-order data, and need autoscaling that can absorb bursts without dropping messages. That's more operational surface area than a cron-triggered batch job.
Three considerations decide it. First, data volume and arrival pattern. Large periodic dumps lean batch. Steady high-frequency events lean streaming. Second, how fresh the answer needs to be. If a one-hour or one-day delay is fine, batch wins on cost and simplicity. If decisions depend on data from the last few seconds, streaming is the only option. Third, infrastructure capacity. Streaming demands a platform that can run 24/7 with the elasticity to absorb traffic spikes.
Many real architectures use both. The lambda-style pattern is common: streaming for real-time alerts and dashboards, batch for deeper retrospective analysis on the same data once it has settled. Streaming is becoming the default for new pipelines as managed services like Dataflow and Pub/Sub make it cheaper to operate, but batch is still the right answer when the workload is genuinely periodic.
On the Professional Cloud Architect exam, expect scenario questions where the latency requirement is buried in the prompt. "The team needs to identify fraudulent transactions before they complete" is a streaming question. "The finance team produces a monthly P&L" is a batch question. Read for the freshness requirement first, then pick the processing model.
My Professional Cloud Architect course covers batch vs streaming data processing alongside the rest of the foundational architecture material.
