Technologies in integration change every few years.
ESBs came and went. Cloud integration platforms arrived. Event streaming took over a large part of the conversation. Now AI agents are changing it again.
But underneath all of that, the same problems keep coming back. How do I route a message to the right place? How do I split a large order into lines and recombine the results? What happens when a message cannot be processed?
The answers to those questions were written down more than twenty years ago, in the book Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf. I still recommend it to every integration architect I mentor.
Why Patterns Still Matter
Patterns give integration teams two things that never go out of date:
- Proven solutions to recurring problems, so you do not reinvent them badly
- A shared vocabulary, so a design can be explained in a sentence
When someone says "we will use a content-based router, then a splitter, and an aggregator at the end", an experienced integration architect can picture the entire flow instantly.
The Patterns I Use Most
Content-based router
Look at the content of a message and send it to the right destination. For example, route orders from different regions to different fulfilment systems.
Splitter and aggregator
Split a message with many items into individual messages, process each one, then combine the results again. Classic for order lines, invoice items or batch records.
Message translator
Convert a message from one format or structure to another. Almost every integration contains at least one.
Content enricher
Add missing information to a message by looking it up elsewhere, such as adding customer details to an order before sending it on.
Canonical data model
Define a common, system-neutral format for key business entities, so each system translates to and from one model instead of to every other system. Powerful, but keep it pragmatic. Overly ambitious canonical models become a bottleneck of their own.
Dead letter channel
Send messages that cannot be processed to a separate place for investigation, rather than losing them or blocking everything else.
Idempotent receiver
Make sure that receiving the same message twice does not cause duplicate effects. Essential in any system with retries.
Competing consumers
Let several consumers read from the same queue to process messages in parallel and scale out.
Patterns in Modern Platforms
Most modern integration platforms implement these patterns directly. MuleSoft, Apache Camel, Spring Integration and cloud integration services all have routers, splitters, aggregators and transformers as building blocks. Knowing the patterns helps you use these platforms well instead of fighting them.
Common Mistakes
- Pattern overload: combining ten patterns where two would do
- Ignoring error patterns: happy-path designs that fall apart on the first bad message
- Forgetting idempotency: retries that cause duplicate orders or payments
- Giant canonical models: trying to model the entire enterprise before delivering anything
Final Thought
Tools will keep changing. The problems will not.
Learn the patterns once, and you will recognize the same solutions in every integration platform you ever work with.