Resequencer
The component that reorders messages — useful when parallel workers publish out of order.
Problem
An INVOIC split into 100 segments processed in parallel can arrive in arbitrary order at the receiver. If order matters (HEAD before LINE before SUMMARY), how to reorder?
Forces
- Parallelism naturally breaks ordering.
- Resequencing requires an in-memory buffer with timeout — OOM risk if timeout is mis-calibrated.
- Some messages may be lost — the resequencer needs a degraded mode.
- EDI often has business ordering (Header → Detail → Summary).
Solution
A consumer that buffers messages indexed by sequenceId and republishes them in order. Typical mechanism: maintain a nextExpected counter, hold messages with id > nextExpected, release as soon as the expected next one arrives. Configured timeout (5-30 min in EDI) to avoid indefinite blocking.
EDI implementation
In EDI, Resequencer is used to reconstruct an INVOIC from parallel-processed segments, or to reorder MDNs that arrive out of order (rare but possible with proxy/load balancer). Apache Camel implementation: `.resequence().header("sequenceNumber").timeout(30000)`. Performance: ensure buffer is released on timeout to avoid OOM.
Anti-patterns
- Infinite timeout — memory leak at the first incomplete sequence.
- Resequencer downstream of a splitter — Composed Message Processor is better.
- Order guaranteed by default without validation — a missing message blocks indefinitely.
Related patterns
- Splitter — often produces disorder.
- Aggregator — recomposes after resequencing.
- Composed Message Processor — higher-level alternative.
Sources
- Hohpe G., Woolf B. — EIP, Resequencer (p. 283). www.enterpriseintegrationpatterns.com/patterns/messaging/Resequencer.html