Skip to content
Software Architecture Guide

Correlation Identifier

Explanation

Section titled “Explanation”

A requester sends a request and later receives a reply. The question is simple: which request does this reply belong to? The Correlation Identifier pattern answers it.

How it works

  • Every request carries an ID that identifies that request uniquely.
  • The replier reads this ID from the request.
  • The replier stores it in a correlation ID field of the reply.
  • The reply therefore holds a token with the same value as the request ID.

The requester reads the correlation ID from the reply. It can then tell which of its requests the reply answers.

Working with a Return Address

A request also needs to say where the reply should go. In RabbitMQ’s remote-call example, the client sends the name of a callback queue along with the request. The server uses it to know where to reply. This is the idea behind the Return Address pattern (see its article). The queue name tells the server where to reply. The correlation ID tells the client which request the reply answers.

Unknown replies

In the same RabbitMQ example, a client may see a reply with a correlation ID it does not know. It can safely discard that message. The reply does not belong to this client’s requests.

For the wider request and reply exchange, see the Request-Reply article.

Example

Section titled “Example”

A web shop sends two “check stock” requests to a warehouse service, one for shoes and one for hats. Request A has ID 101 and request B has ID 102. The warehouse sends two replies. Each reply carries the matching ID as its correlation ID. The shop reads 102 on one reply and knows it answers the hat request. A reply carrying ID 555 is unknown to the shop, so the shop discards it.

Two requests in flight; each reply carries the ID of its request.

Diagram source 
sequenceDiagram
  participant R as Requester
  participant P as Replier
  R->>P: Request (ID 101, reply-to: callback queue)
  R->>P: Request (ID 102, reply-to: callback queue)
  P-->>R: Reply (correlation ID 102)
  P-->>R: Reply (correlation ID 101)
  Note over R: Each reply is matched to its request by ID

Checks

Section titled “Checks”
  • The design states that each request carries a unique ID.
  • The design states that the replier copies the request ID into the correlation ID field of the reply.
  • Where requests expect replies on a callback queue, the document names that queue as the return address sent with the request.
  • The design says what a requester does with a reply whose correlation ID it does not recognize.
Section titled “Related”

Sources

Section titled “Sources”