Correlation Identifier

A Correlation Identifier is a unique value placed on a message that lets a receiver associate that message with related ones — most commonly to match a reply to its original request. It is the thread that ties together messages in an otherwise stateless, asynchronous flow.

The problem it solves is matching in a sea of concurrent messages. When many requests are outstanding and replies arrive asynchronously and possibly out of order, the requestor must know which reply answers which request. A correlation id carried from request to reply provides that link without shared connection state.

How It Works

The originator generates a unique id (a UUID or a business key) and stamps it on the outgoing message, usually in a header. Any component that produces a related message — a reply, a split part, a follow-up event — copies that id onto its output. Receivers index pending work by correlation id; when a correlated message arrives, they look up the matching context and proceed.

The same mechanism scopes aggregation (group parts that share an id), supports deduplication (an id seen before is a duplicate), and enables distributed tracing (propagate the id across services as a trace or business correlation id).

request{ correlationId: 9f2 } ... reply{ correlationId: 9f2 } --> matched

When to Use It

Use it for request-reply matching, for grouping messages in an aggregator, for tracking a business transaction across many services and steps, and for end-to-end tracing and auditing. It is indispensable in asynchronous and distributed systems.

There is rarely a reason not to propagate a correlation id; even fire-and-forget flows benefit from it for observability.

Trade-offs

The pattern is cheap but requires discipline: every component must propagate the id faithfully, or the chain breaks. Storing pending contexts keyed by id consumes memory and needs timeouts to evict abandoned entries. Choosing the id scheme (random vs business key) affects deduplication and privacy. The benefit is reliable association across asynchronous, distributed messages.

Related Patterns

Request-Reply relies on it to pair messages. The Aggregator uses it to group parts. A Process Manager tracks long-running flows by correlation id. An Idempotent Receiver can use it as the dedup key.

Example

A checkout flow assigns orderId=ORD-771 as a correlation id. The payment, inventory, and shipping services each include it on their events and replies, so the order orchestrator can correlate all activity for that order and a tracing system can show the full timeline end to end.