Spring Batch vs Kafka Streams — Bounded Jobs vs Streaming Pipelines

Q: Spring Batch vs Kafka Streams — Bounded Jobs vs Streaming Pipelines

**Spring Batch** suits **scheduled, bounded** workloads where you process a finite dataset within an SLA window — nightly ETL, monthly billing, periodic reconciliation. **Kafka Streams / Flink** suits **continuous, unbounded** workloads where data arrives as events and downstream consumers need fresh state within seconds — fraud detection, real-time aggregations, event-driven pipelines. The deciding factors are **freshness SLA**, **dataset boundedness**, and **operational model**. When freshness SLA tightens to seconds or the source becomes an event stream rather than a table, the cost of running a batch job every minute exceeds the cost of operating a streaming topology — switch.

Intermediate·3 min read·

ConfluentLinkedInNetflixUberStripe

Fast recall

Quick revision

Core answer

Spring Batch suits scheduled, bounded workloads where you process a finite dataset within an SLA window — nightly ETL, monthly billing, periodic reconciliation. Kafka Streams / Flink suits continuous, unbounded workloads where data arrives as events and downstream consumers need fresh state within seconds — fraud detection, real-time aggregations, event-driven pipelines. The deciding factors are freshness SLA, dataset boundedness, and operational model. When freshness SLA tightens to seconds or the source becomes an event stream rather than a table, the cost of running a batch job every minute exceeds the cost of operating a streaming topology — switch.

Interview Answer3 min

The choice between Spring Batch and Kafka Streams comes down to freshness SLA, source shape, and operational maturity.

Spring Batch fits when:

Source is a finite snapshot — file, table, query result
Freshness SLA is hours, days, or longer
Operations team is RDBMS-strong without a Kafka platform
Workload is naturally bounded — nightly ETL, monthly billing, periodic reconciliation

Kafka Streams or Flink fits when:

Source is an event stream — Kafka topic, CDC log, IoT telemetry
Freshness SLA is seconds or low minutes
Workload involves windowed aggregations, stream joins, stateful pattern detection
Platform team owns Kafka and exactly-once expertise

The deciding factors:

Freshness SLA — hours = batch; seconds = streaming
Dataset boundedness — finite snapshot = batch; continuous stream = streaming
Operational maturity — Kafka cluster, schema registry, monitoring, on-call expertise
Reprocessing cost — batch re-runs a job; streaming replays from offsets and restores state

The migration path from batch to streaming:

Add CDC (Debezium) to the source database — emits row changes as Kafka events
Build a streaming topology that produces the same output the batch job did
Run both in parallel for a quarter; verify parity
Cut over consumers; keep batch as weekly reconciliation safety net

Hybrid Lambda/Kappa architectures:

Real-time approximate results from streaming
Accurate eventual results from batch
Common in finance — intraday risk via streaming, end-of-day reconciliation via batch

Common pitfalls:

Defaulting to streaming because it's modern — most workloads are still bounded
Defaulting to batch when freshness needs tighten — batch can't follow to seconds
Underestimating Kafka operational complexity — schema registry, exactly-once, state store sizing
Lambda architecture doubling maintenance burden

In an interview I'd emphasize that the question is rarely 'which is better' — it's 'what's the freshness SLA and what shape is the source?' The right tool follows from those two answers.

Interview-ready guide

Interview answer