75 messaging and reliability patterns.
The original Enterprise Integration Patterns language for channels, routing, transformation, endpoints and operational messaging concerns.
Foundational ways independent applications exchange data and invoke behavior.
Exchange batches through files when systems are loosely connected in time or cannot call each other directly. The integration owns file naming, scheduling, transformation and recovery.
Let applications coordinate through a common data store. This can simplify consistency but also couples participants to a shared schema, ownership model and release process.
Expose behavior through a callable interface so one application invokes another directly. It is intuitive but creates temporal and availability coupling between caller and provider.
Applications exchange self-contained messages through channels, allowing senders and receivers to be decoupled in location and time while supporting reliable asynchronous processing.
The core vocabulary and building blocks of message-oriented integration.
Use a logical channel as the transport boundary between producer and consumer. Channel semantics define delivery, ordering, durability and who may receive each message.
Package data and metadata into a self-contained unit that can move independently through an integration flow. Headers carry routing and control context while the body carries business content.
Break processing into independent filters connected by channels. Each step performs one responsibility, making the flow easier to compose, test and evolve.
Insert routing logic that chooses one or more destinations without changing the message body. Centralizing the decision keeps producers and consumers unaware of each other.
Translate from one representation into another at an integration boundary so connected applications can evolve without sharing the same data shape.
Encapsulate the protocol-specific code that sends to or receives from a channel. The application works through an endpoint rather than directly against transport details.
How messages are transported, delivered, isolated and bridged between systems.
Deliver each message to one consumer, even when several consumers compete for work. This supports scalable task distribution without duplicate processing by design.
Publish once to a channel that fans the event out to every interested subscription. Producers remain unaware of how many consumers exist.
Use a distinct channel for each message type or contract. The channel itself communicates what kind of payload consumers should expect.
Move messages that are structurally or semantically invalid to a dedicated channel for inspection instead of repeatedly failing normal processing.
Move undeliverable messages to a separate channel that preserves failure context and supports investigation, repair and controlled replay.
Persist messages so infrastructure failures do not silently lose them. Delivery guarantees still require idempotent consumers and explicit failure handling.
Translate between an application's native interface and a messaging channel. The adapter isolates protocol and transport concerns from business logic.
Connect separate brokers or channel technologies and forward messages between them while preserving the semantics needed by each side.
Standardize channels, contracts and adapters around a shared messaging backbone so applications can join or leave with limited point-to-point coupling.
How message intent, identity, timing and reply behavior are represented.
Represent a request to perform an action as a message. The receiver interprets the message as an instruction rather than merely as data or notification.
Send a business document or data structure whose content matters more than immediate timing. The receiver decides how to process the transferred information.
Publish a notification that something has happened. Consumers react independently and the producer does not prescribe a specific action.
Use a request message and a corresponding reply message, usually over separate channels, with addressing and correlation data that connect the interaction.
Include the reply destination with the request so the provider can respond without being coupled to a specific caller or hardcoded channel.
Carry a stable identifier that lets the receiver match a reply or related message to the originating request and trace a distributed interaction.
Split a large logical payload into an ordered sequence of messages carrying sequence position and completion information so it can be reconstructed safely.
Attach a time-to-live or expiry timestamp so stale work is removed or diverted instead of producing outdated side effects.
Include an explicit version or format identifier so consumers can select the correct parser, schema and transformation as contracts evolve.
How messages are split, directed, combined and coordinated across processing steps.
Inspect message content and route to the destination whose rules match. Keep routing rules visible and maintainable because they often become a frequent change point.
Evaluate criteria and pass only messages that should continue. Non-matching messages are discarded or diverted according to the operational policy.
Let recipients advertise capabilities and make routing decisions from runtime state rather than a fixed destination list.
Determine a set of recipients and send a copy to each one. The recipient list can be calculated from content, configuration or runtime context.
Break a composite message into smaller messages that can be processed independently, preserving identifiers needed for later aggregation or tracking.
Collect correlated messages until a completion condition is satisfied, then publish a single result produced by an aggregation algorithm.
Buffer related messages and release them in the intended sequence based on sequence numbers or ordering rules.
Combine splitting, routing and aggregation into a coordinated flow that processes each element correctly and rebuilds a meaningful result.
Send a request to several recipients in parallel and aggregate their replies into one result using a defined completeness and selection rule.
Attach the remaining itinerary to the message and let each processor forward it to the next listed step.
Use a stateful coordinator that tracks process progress and determines the next action from business state, events and completion rules.
Place a broker between participants to route, transform and govern messages while shielding senders from destination-specific details.
How messages are wrapped, enriched, reduced and normalized between data models.
Wrap an application's native payload in an integration envelope that carries required headers, security or transport metadata, then unwrap it at the destination.
Look up or compute missing information and add it to the message before forwarding it to the next participant.
Remove unneeded fields or simplify structure so downstream consumers receive only the data they require.
Store bulky content externally and send a small claim token that authorized consumers can use to retrieve the full payload.
Route each incoming format through the appropriate translator and produce one normalized representation for downstream processing.
Define a shared integration model and translate each application format to and from it, reducing the number of direct pairwise transformations.
How applications consume, produce and safely interact with messaging infrastructure.
Expose a domain-friendly interface that hides channel names, message construction and transport APIs from the rest of the application.
Map domain objects to message representations at the endpoint boundary so business code is not coupled to broker-specific message types.
Group message operations and related state changes into a transaction boundary so work is committed or rolled back consistently.
Ask the channel for messages on the consumer's schedule. Polling gives the application control over timing but requires sensible intervals and empty-read behavior.
Register a handler that the messaging infrastructure invokes whenever a message arrives, enabling low-latency processing without explicit polling loops.
Run multiple consumers against the same point-to-point channel so workload is distributed while each message is handled by only one instance.
Use a dispatcher to receive from one channel and assign each message to an appropriate local performer or worker.
Apply selection criteria at the consumer or subscription so only matching messages are delivered to that endpoint.
Keep a persistent subscription and retain events while the consumer is offline, allowing it to resume without losing relevant messages.
Design processing so receiving the same message more than once has the same effect as receiving it once, usually through deduplication or naturally idempotent operations.
Connect a message endpoint to an application service and translate an incoming message into a normal method invocation, keeping business logic independent of transport.
How distributed message flows are observed, tested, traced and operated.
Use a separate management channel for configuration, health, diagnostics and operational commands instead of mixing control traffic with business messages.
Temporarily divert selected traffic through an additional path and return it to the normal route afterward, without permanently redesigning the flow.
Send a copy of each message to a secondary channel for observation while allowing the original message to continue unchanged.
Attach a record of the components a message has traversed so teams can reconstruct its path and understand where transformations or failures occurred.
Capture selected message metadata or payload references in a separate store for search, reporting, audit and replay without changing the primary flow.
Place a proxy between requestor and service that records correlation state, forwards requests and rewrites replies so the original interaction remains traceable.
Inject known test messages into the live path, separate their results and verify the outcome so hidden processing failures can be detected continuously.
Remove obsolete messages from a channel in a controlled way before a test, migration or operational reset.
Cloud reliability patterns for transient faults, distributed consistency, load protection, monitoring and recoverable processing.
Contain transient and long-running failures before they cascade through an integration flow.
Repeat an operation after a controlled delay when the failure is likely to be transient. Bound the number of attempts, add backoff and jitter, and combine retries with idempotency and an explicit final failure path.
Track failures and temporarily stop calls to an unhealthy dependency. Closed, open and half-open states let the system fail fast while still testing whether the dependency has recovered.
Partition resources and workloads into isolated pools so one overloaded tenant, connector or dependency cannot consume all available capacity or spread failure across the entire solution.
Coordinate multi-step work and restore a valid business state when part of a distributed operation fails.
Record enough business context to execute compensating actions for completed steps. Compensation restores a valid state rather than attempting an impossible distributed rollback.
Break a distributed transaction into local transactions connected by commands or events. Each completed step has a compensating action so failures can be recovered without a global database transaction.
Control demand, isolate capacity and keep downstream services within safe operating limits.
Place a durable queue between producers and consumers so bursts are buffered and processed at a sustainable rate. Capacity can then scale independently on either side of the queue.
Measure consumption and delay, reject or degrade requests that exceed defined limits. Good throttling communicates limits clearly and protects both shared capacity and important workloads.
Detect unhealthy work, coordinate recovery and keep long-running processing observable and recoverable.
Expose functional health checks that external monitoring can call regularly. Checks should distinguish basic process liveness from readiness and dependency health without leaking sensitive details.
Use a lease or distributed coordination mechanism to select one active leader while other instances remain eligible to take over. Leadership must expire safely when the current owner fails.
Separate coordination, remote work and supervision. Durable step state and completion deadlines allow a supervisor to detect failed or timed-out work and arrange retry, recovery or compensation.
Enterprise Messaging preserves the Enterprise Integration Patterns catalogue and its CC BY 3.0 attribution. Reliability & Delivery links to Microsoft Azure Architecture Center guidance. GateSift summaries, diagrams, Azure mappings and analyzer signals are original and do not imply endorsement by either source.