Skip to content
Software Architecture Guide

Return Address

Explanation

Section titled “Explanation”

A service that receives a request must answer somewhere. Without help, it does not know where. Return Address solves this: the requester puts the reply destination into the request itself.

The address travels in the message header, not in the data. It describes where the reply goes, not what the message says. The replier reads the header and sends its answer to that channel. It needs no list of reply destinations in advance.

This pattern supports Request-Reply (see the article on that pattern). Request-Reply uses a pair of messages, and each message travels on its own channel. The request channel can be point-to-point or publish-subscribe.

Return Address usually works with a Correlation Identifier. This is a unique ID that tells the requester which request a reply belongs to. The address says where the reply goes. The identifier says which request it answers.

Real products use the same idea. In RabbitMQ RPC (remote procedure call over messaging), the client sends the name of a callback queue along with its request. The client creates its own exclusive callback queue when it starts. That is a temporary reply queue.

The correlation_id property pairs with reply_to. If a client sees an unknown correlation_id, it can safely discard the message. That is a basic validation step.

Example

Section titled “Example”

An order service receives price requests from many client applications. Each client creates its own reply queue at startup. Each client sends a request with its queue name in the header and a unique ID. The order service reads the header and sends the answer to that queue, copying the ID into the reply. The client checks the ID. If it does not know the ID, it discards the message.

Trade-offs

Section titled “Trade-offs”

The replier trusts the address in each request. The verified facts here do not cover how to guard against untrusted addresses, so a design needs its own validation rules. The reply-side check on the correlation ID is only a basic step.

Each requester needs its own reply channel. That adds channels to create and manage.

The replier sends its answer to the channel named in the request header.

Diagram source 
sequenceDiagram
  participant C as Requester
  participant Q as Request channel
  participant S as Replier
  participant R as Requester reply channel
  C->>Q: Request (reply-to header, correlation ID)
  Q->>S: Request
  S->>R: Reply (same correlation ID)
  R->>C: Reply

Checks

Section titled “Checks”
  • Request messages carry the reply destination in a header, not in the business data.
  • Replies are matched to requests with a correlation identifier alongside the return address.
  • Requesters discard replies whose correlation ID they do not recognize.
Section titled “Related”

Sources

Section titled “Sources”