Every enterprise architecture eventually runs into the same problem: two systems need to exchange data, and the obvious way to connect them creates more risk than it solves. Enterprise integration patterns exist because that problem isn't new. It's been solved, documented, and reused across messaging systems, service buses, and now event-driven microservices.
This guide covers what enterprise integration patterns are, why they still matter decades after they were first cataloged, the core categories every architect should know, a scannable patterns list, and a few real-world examples, including a short .NET implementation.
What Are Enterprise Integration Patterns?
Enterprise integration patterns are proven, technology-independent solutions to the recurring problems that come up when connecting applications, services, or systems, particularly over asynchronous messaging. Instead of designing a routing strategy or a data transformation approach from scratch, an architect reaches for a pattern that's already been tested across a wide range of implementations.
The term comes largely from Gregor Hohpe and Bobby Woolf's 2003 book Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, which cataloged 65 patterns along with a shared visual notation for describing them. The patterns aren't tied to a specific vendor or protocol. The same Content-Based Router shows up whether the underlying transport is JMS, MSMQ, Kafka, or Azure Service Bus, because the pattern describes the shape of the solution, not the implementation.
Anyone who has used design patterns in object-oriented programming (Factory, Observer, Strategy) will recognize the idea, just applied to system-to-system communication instead of class design. Enterprise integration patterns give teams a shared vocabulary: when one architect says "we need a Recipient List here," everyone in the room knows the problem being solved without needing a diagram.
Why Enterprise Integration Patterns Matter
The patterns were cataloged during the era of JMS, SOAP, and enterprise service buses, but the underlying problems didn't disappear when architectures shifted toward microservices and event-driven design. They just moved.
A modern system built on Kafka or a cloud event bus still needs to decide how a message gets routed to the right consumer, how a payload from one service gets translated into the shape another expects, and what happens when a downstream system is temporarily unavailable. Those are the exact problems Content-Based Router, Message Translator, and Dead Letter Channel were built to solve. The transport changed. The problems mostly didn't.
Working from a known pattern instead of a one-off solution pays off in fewer missed edge cases, since the pattern documents common failure modes alongside the fix, and in integration code where the intent is named instead of buried in custom logic.
Core Categories of Enterprise Integration Patterns
Most of the 65 cataloged patterns fall into four practical categories. Knowing these four well does more for day-to-day integration work than memorizing the full list.
Messaging patterns
Messaging patterns govern how systems exchange information asynchronously through channels rather than direct calls. A Point-to-Point Channel guarantees exactly one consumer processes a given message, which fits work that shouldn't be duplicated, like charging a payment. A Publish-Subscribe Channel broadcasts a message to every interested consumer, useful for event notifications where several systems need to react to the same change. Guaranteed Delivery and Dead Letter Channel cover the failure cases: a message that can't be delivered, or a consumer that can't process it, without it getting lost or stalling the channel.
Routing patterns
Routing patterns decide where a message goes without the sender needing to know. A Content-Based Router inspects a message and sends it down a different path depending on what's inside it, for example routing high-value orders to a manual review queue. A Splitter breaks a composite message into pieces for separate processing, and an Aggregator does the reverse, recombining related messages before passing them along. These patterns keep routing decisions out of the systems doing the actual business work.
Transformation patterns
Two systems rarely agree on a data format, and transformation patterns close that gap. A Message Translator converts one system's representation into another's. A Canonical Data Model takes that further by defining one shared format that every system transforms into and out of, instead of a custom translator for every pair of systems. That difference compounds with scale: five systems connected point-to-point need up to twenty translation paths; routed through a canonical model, they need five.
Endpoint patterns
Endpoint patterns describe how application code connects to the messaging infrastructure itself. A Messaging Gateway hides the messaging API behind a domain-specific interface so the rest of the application isn't coupled to a particular broker. Competing Consumers let multiple instances of a service pull from the same channel to scale throughput, and an Idempotent Receiver guards against processing the same message twice, which matters more once retries and at-least-once delivery are in play.
Enterprise Integration Patterns List (Quick Reference)
A scannable list of the patterns that come up most often in practice, beyond the ones already covered above:
- Channel Adapter (Adapter): connects a messaging system to an external application or API that wasn't built with messaging in mind, often the entry point for legacy system integration.
- Recipient List: routes a copy of a message to a dynamically determined set of recipients, rather than one fixed destination.
- Scatter-Gather: sends a request to multiple recipients and reassembles their responses into one, common in pricing or quote-comparison workflows.
- Resequencer: restores the original order of messages that arrived out of sequence, which matters more than it sounds once parallel consumers are involved.
- Claim Check: stores a large payload externally and passes a reference through the messaging system instead of the full payload, keeping channels lightweight.
- Wire Tap: copies a message to a secondary channel for monitoring or auditing without altering the main flow.
- Correlation Identifier: attaches an ID to related messages so a reply can be matched back to its original request in an asynchronous exchange.
- Process Manager / Routing Slip: coordinates a multi-step message flow, either through centralized logic (Process Manager) or by attaching the steps to the message itself (Routing Slip).
- Saga: manages a business transaction spanning multiple services without a distributed lock. It isn't one of the original 65 Hohpe and Woolf patterns, it predates the EIP catalog and comes out of earlier distributed transaction research, but it solves the same class of problem and shows up constantly alongside EIPs in modern, service-based architectures.
Real-World Enterprise Integration Patterns Examples
Patterns are easiest to understand next to an actual integration problem.
Enterprise application integration example: order processing
An order placed on an e-commerce storefront typically needs to reach inventory, payment, and shipping systems, each with its own data model and failure modes. A Publish-Subscribe Channel broadcasts the "order placed" event. A Content-Based Router sends international orders through an extra customs step that domestic orders skip. If payment or inventory reservation fails partway through, a Saga rolls back the steps that already succeeded instead of leaving the order half-completed.
CRM-to-ERP synchronization
Keeping a CRM and an ERP system aligned is a common integration request, and a good showcase for the Canonical Data Model. Rather than writing a direct translator between the CRM's contact schema and the ERP's customer schema, both systems map to and from a shared internal format. Adding a third system later means writing one new translator, not two more.
.NET example: a content-based router
Enterprise integration patterns in .NET usually run through a service bus library like NServiceBus, MassTransit, or Azure Service Bus topics and subscriptions, rather than hand-rolled routing. The pattern itself is simple enough to see clearly in plain C#, though:
public interface IOrderQueue
{
void Send(Order order);
}
public class ContentBasedOrderRouter
{
private readonly IOrderQueue _internationalQueue;
private readonly IOrderQueue _domesticQueue;
public ContentBasedOrderRouter(IOrderQueue internationalQueue, IOrderQueue domesticQueue)
{
_internationalQueue = internationalQueue;
_domesticQueue = domesticQueue;
}
public void Route(Order order)
{
var queue = order.ShippingCountry == "US" ? _domesticQueue : _internationalQueue;
queue.Send(order);
}
}
The router doesn't know how the order was created or what happens after it's queued. It only makes one routing decision, which is the point: the pattern isolates that logic so it can change without touching the systems on either side of it.
For the full catalog beyond what fits in a guide like this, Hohpe and Woolf's original book remains the definitive reference for anyone who wants all 65 patterns with their complete notation.
Choosing patterns for your integration
Most projects don't need all 65 patterns, or even every category above, on day one. They need the small set that solves the specific coupling, routing, or transformation problem currently blocking a project, applied by people who've already worked through the tradeoffs elsewhere. That's usually where custom integration work earns its keep: picking the smallest set of patterns that actually fits the systems involved, instead of over-architecting around a textbook diagram.
FAQ
What is enterprise integration?
Enterprise integration is the broader discipline of connecting an organization's applications, data, and services so they operate as one coherent system rather than a set of disconnected silos. Enterprise integration patterns are the reusable design solutions practitioners draw on to solve the specific problems, routing, transformation, coupling, failure handling, that come up while doing that work. Enterprise Application Integration (EAI) is often used as a near-synonym, especially for middleware-heavy, on-premises integration projects.
What are integration patterns?
Integration patterns are documented, reusable solutions to the problems that repeatedly show up when connecting two or more systems: how to route a message to the right destination, how to translate one system's data format into another's, how to guarantee delivery when a receiver is temporarily unavailable. They give architects a shared vocabulary instead of everyone naming the same well-understood problem differently.