# Request-Reply

**In short:** Request-Reply lets a requestor send a message on one channel and get the answer on another. A correlation ID or a return address tells the requestor which reply belongs to which request.

## Explanation

Request-Reply is a messaging pattern with two channels. The requestor sends a request on the request channel. The replier sends its answer back on a separate reply channel. (See Message Channel and Messaging for the basics.)

The two channels often differ in kind. The request channel can be point-to-point (one receiver gets each message) or publish-subscribe (many receivers get a copy). The reply channel is almost always point-to-point. That way the reply goes only to the requestor.

Two questions come up in practice.

**Which reply answers which request?** A requestor may have several requests open at once. A Correlation Identifier solves this. It is a token in the reply with the same value as the request's ID. The replier reads the ID from the request and stores it as the correlation ID in the reply. The requestor then matches the two.

**Where should the reply go?** The request can carry a Return Address. It tells the replier where to send the reply, so the replier does not need to know the address in advance. The address sits in the message header because it is not part of the transmitted data.

In BPMN (a process modeling notation), a message catch event makes a process wait until a matching message arrives. Messages in BPMN go from one sender to one recipient. A requestor can model its wait for a reply this way.

## Example

An online shop sends a "create order" request to an order service. The request carries an ID and a return address in its header. The order service handles it. It copies the ID into the correlation ID of its reply and sends the reply to the return address. The shop has several orders open at once. It uses the correlation ID to pair each reply with the right order.

A request and its reply travel on separate channels, matched by the correlation ID.

```mermaid
sequenceDiagram
  participant R as Requestor
  participant Q1 as Request channel
  participant P as Replier
  participant Q2 as Reply channel
  R->>Q1: Request (ID, return address)
  Q1->>P: Request
  P->>Q2: Reply (correlation ID = request ID)
  Q2->>R: Reply
```

## Checks

- The reply channel is point-to-point, so replies reach only the requestor.
- Replies carry a correlation ID equal to the ID of the request they answer.
- Requests carry a return address in the message header, so the replier does not need to know it in advance.

## Related

- [Correlation Identifier](https://arc.fuet.ch/concepts/integration/correlation-identifier.md)
- [Return Address](https://arc.fuet.ch/concepts/integration/return-address.md)
- [Message Channel](https://arc.fuet.ch/concepts/integration/message-channel.md)
- [Messaging](https://arc.fuet.ch/concepts/integration/messaging.md)
- [Point-to-Point Channel](https://arc.fuet.ch/concepts/integration/point-to-point-channel.md)
- [Publish/Subscribe Channel](https://arc.fuet.ch/concepts/integration/publish-subscribe-channel.md)
- [Synchronous vs. Asynchronous Communication](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-communication.md)
- [BPMN Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-event.md)

## Sources

- [Request-Reply - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReply.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09
- [Correlation Identifier - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/CorrelationIdentifier.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09
- [Return Address - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/ReturnAddress.html) — enterpriseintegrationpatterns.com, accessed 2026-11-09
- [Message events | Camunda 8 Docs](https://docs.camunda.io/docs/components/modeler/bpmn/message-events/) — docs.camunda.io, accessed 2026-11-09