Send a request with enough metadata to identify where and how to respond.
Message Construction
Correlation Identifier
Carry a stable identifier that lets the receiver match a reply or related message to the originating request and trace a distributed interaction.
How does a requestor that has received a reply know which request this is the reply for?Adapted from Enterprise Integration Patterns under CC BY 3.0. The visualization and explanatory content on this page are original GateSift material.
Original GateSift visualization
How Correlation Identifier works
A request and its response are connected even when messaging is asynchronous.
Request
Correlation Identifier
Reply
Apply Correlation Identifier to preserve the reply path or correlation context.
Return the response to the correct requester and match it to the original request.
What this pattern helps you decide
Carry a stable identifier that lets the receiver match a reply or related message to the originating request and trace a distributed interaction.
What happens when processing fails or the same message is delivered twice?
Where does state, correlation or routing configuration live?
How will operators trace the message and understand the decision path?
Where you may see it
- Service Bus CorrelationId
- x-correlation-id header
- BizTalk correlation sets
How the analyzers can surface it
- APIM correlation header
- BizTalk context properties and filters
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
Source, licence and attribution
The pattern name and selected problem statement are adapted from Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf under CC BY 3.0. GateSift summaries, Azure mappings, analyzer guidance and diagrams are original. No endorsement by the original authors is implied.