Enterprise Integration Patterns
Enterprise integration patterns are reusable designs for connecting independent applications with messages. They help you choose how systems exchange data, route work, transform formats, recover from failure, and remain understandable as integrations grow.
itDistributed systems, messaging, and integration | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Enterprise Integration Patterns
Enterprise Integration Patterns are a vocabulary for the awkward moment when independently built systems must exchange information or coordinate work. They are not a broker, framework, or large ceremonial appliance with a blinking dashboard. They are names for the choices hiding inside the wires, which is fortunate because unnamed choices tend to return later wearing a production incident badge.
Before this vocabulary, a team could connect sender to receiver directly, then connect the next sender to the next receiver, and eventually produce a landscape of private agreements. A message gives that agreement a unit of exchange. A command asks a receiver to act, a document carries a business record, and an event reports a fact that already happened. Those are not interchangeable labels. The receiver, the reply path, and the ownership rules change with the message's intent.
Next comes the channel, the logical route between endpoints. Point-to-point means one consumer handles a work item. Publish-subscribe means each interested subscriber receives a copy of a fact. A router chooses a destination, a splitter creates parts, and an aggregator brings related results back together. The terminology can sound like a box of spare plumbing. It earns its keep when a design review can ask which component owns routing instead of asking why three services have made different guesses.
The surprise is that delivery is not a footnote. A retry may happen after work was completed but before the response arrived. At-least-once delivery can therefore produce duplicates. An idempotent receiver handles the same work again without repeating its intended effect. Dead-letter channels, correlation identifiers, message history, traces, logs, and replay procedures are part of the flow, not the paperwork added after the flow has misbehaved in public.
Read the intro when the whole path needs a calm explanation. Use the slides to compare message intent, channels, routing, transformation, and endpoint roles. Keep the cheatsheet nearby when a named pattern is on the tip of the tongue. The practice reference turns the vocabulary into a review sequence, and the exercise asks you to design one complete order flow. After that, the reference links lead into concrete frameworks, where the patterns stop being nouns and start becoming decisions with consequences.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.enterpriseintegrationpatterns.com/patterns/messaging/
Supports
- Messaging pattern families and named patterns
- Technology-independent pattern language
- Channel, construction, routing, transformation, endpoint, and management concepts
- https://learn.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber
Supports
- Publisher-subscriber components and decoupling
- Duplicate delivery, idempotency, schema evolution, correlation, ordering, and backpressure considerations
- https://github.com/stn1slv/awesome-integration
Supports
- Discovery of Enterprise Integration Patterns and integration tooling
- https://camel.apache.org/manual/enterprise-integration-patterns.html
Supports
- Apache Camel implementations of Enterprise Integration Patterns
- https://docs.spring.io/spring-integration/reference/overview.html
Supports
- Spring Integration messaging and endpoint concepts
- https://www.asyncapi.com/
Supports
- AsyncAPI as an asynchronous API contract tool
- https://www.enterpriseintegrationpatterns.com/patterns/messaging/Preface.html
Supports
- Origins of the Enterprise Integration Patterns work from 2001 through the PLoP papers
- https://www.enterpriseintegrationpatterns.com/gregor.html
Supports
- 2002 PLoP paper and 2003 book and site history
- https://camel.apache.org/camel-dna/
Supports
- Apache Camel 1.0 release and pattern-oriented route history
- https://camel.apache.org/blog/2026/06/camel-dna-19-years/
Supports
- Apache Camel 2.0 and 3.0 architectural milestones
- https://spring.io/blog/2007/12/14/spring-integration-a-new-addition-to-the-spring-portfolio
Supports
- Spring Integration announcement and its Enterprise Integration Patterns inspiration
- https://spring.io/blog/2009/02/13/spring-integration-in-10-minutes
Supports
- Spring Integration 1.0 GA release
- https://spring.io/blog/2014/11/24/spring-integration-java-dsl-1-0-ga-released
Supports
- Spring Integration Java DSL 1.0 GA release
- https://docs.mulesoft.com/general/pricing
Supports
- Anypoint Platform integration pricing model
- https://boomi.com/platform/integration/
Supports
- Boomi integration platform
- https://docs.workato.com/en/pricing.html
Supports
- Workato integration and orchestration editions
- https://wso2.com/integration-platform/integrator/
Supports
- WSO2 Integrator open-source and iPaaS deployment options
- https://stripe.com/blog/idempotency
Supports
- Idempotency keys, ambiguous failures, retries, backoff, and jitter
- https://docs.aws.amazon.com/wellarchitected/2023-04-10/framework/rel_mitigate_interaction_failure_limit_retries.html
Supports
- Retry limits, exponential backoff, jitter, idempotency, and queue-related failure risks
