Spring Batch vs Spring Integration — When to Use Each

Spring Batch and Spring Integration solve fundamentally different problems but are frequently combined.

Spring Batch — structured bulk processing:

• Designed for: processing millions of records from a file or database on a schedule
• Key features: JobRepository for state persistence, restart from failure, skip/retry policies, partitioned parallel processing, chunk-level transaction management
• Use when: defined start, defined end, need to track how many records were processed, skipped, committed

Spring Integration — event-driven message routing:

• Designed for: connecting systems and routing messages in real time
• Key features: message channels, adapters (file system, JMS, AMQP, SFTP, email), transformers, routers, filters
• No concept of job state, checkpointing, or restart — continuous pipeline

The canonical hybrid pattern:

• Spring Integration watches an S3 bucket or SFTP folder for new files
• When a file arrives, Integration launches a Spring Batch job with the file path as a JobParameter
• Spring Batch reads, processes, and writes the file's records with full fault tolerance
• Integration handles the event-driven trigger; Batch handles the heavy data processing

Decision rule:

• Bounded dataset, needs restart/skip/retry — Spring Batch
• Continuous event stream, system integration, message routing — Spring Integration
• Both, with Batch triggered by Integration events — standard enterprise pattern

Common pitfalls:

• Using Integration for bulk processing because it 'feels lighter' — works at small scale, breaks when you need restart
• Using Batch for real-time events because the team already knows it — chunk commits add latency
• Not using RunIdIncrementer when launching Batch from Integration — restart semantics get confusing

In an interview I'd emphasize that the question is rarely 'which one' — it's usually 'how do they fit together'.