Spring Batch parallel flows: make dependency order explicit

Parallel is not ordered

A settlement job can import receipts while another branch loads an immutable exchange-rate snapshot. A split flow schedules both branches, but it does not make either branch finish before the other reads shared state. Put reconciliation after the split joins, and make the input artifacts durable. If one branch fails, inspect the overall job status and both StepExecutions before deciding whether to restart. Flow status can differ from the status of one step.

Design for partial completion

One branch may commit all its chunks while the other fails. Restart should reuse the completed branch only when its output still matches the same manifest and job parameters. Otherwise fail for reconciliation or create a new job instance. Do not make one branch truncate a shared table that the other branch is reading. Pinned input and idempotent writes allow replay without guessing.

Test adverse scheduling

Delay the receipt branch after its first chunk while the rate branch completes, then reverse their relative timing. Reconciliation must not start until both have reached the required terminal state. Assert the final result by business key, not by log order. A second test should fail one branch and verify that the committed output of the other is visible for operator review, not silently discarded.

Implementation contract

Flow parallelInputs = new FlowBuilder<SimpleFlow>("settlementInputs")
    .split(settlementTaskExecutor)
    .add(receiptImportFlow, exchangeSnapshotFlow)
    .build();
// Configure reconciliation after parallelInputs has joined both branches.

Cost and verification

Parallel flows shorten wall time when branches are independent and resources are available. They also increase peak database and I/O demand and complicate partial-failure review.

Common Mistakes

• Do not read another branch’s output before the split has joined.
• Do not assume a failed branch rolls back work already committed by its sibling.
• Do not treat log ordering as an execution dependency.

Read next

Spring Batch flow status: distinguish step failure from job restartability, Spring Batch chunks: a later failure does not erase an earlier commit, Spring Batch writers: use a stable source key when a chunk is replayed, Spring Batch job scope: avoid a shared bean in partition workers, Spring Batch restart input: pin the manifest before resuming a cursor.