Request-Reply Pattern

You have seen request-response. The client calls the server directly and waits. Simple, but tightly coupled. Both sides must be available at the same time, and the client must know the server's address.

Now imagine you want the same semantics (send a request, get a response) but through a message queue. The client sends the request to a queue, a server picks it up, processes it, and sends the reply to another queue. The client listens on the reply queue for its answer.

Why would you do this? Because the queue gives you everything direct calls lack:

• Temporal decoupling. The server can be temporarily down when the request is sent. The message waits in the queue until the server is ready.
• Load leveling. If 10,000 requests arrive in a burst, the queue buffers them and the server processes them at its own pace. No dropped requests.
• Location transparency. The client does not know or care which server instance handles the request. Multiple servers can compete on the same request queue.

This is the request-reply pattern (sometimes called RPC over messaging), and it is used by RabbitMQ, Azure Service Bus, NATS, and any system that needs request-response semantics with queue-level resilience.

The tricky part: when the reply arrives on the reply queue, how does the client know which request it belongs to? If the client sent 50 requests concurrently, it needs to match each reply to its original request.

The answer is a correlation ID. The client generates a unique ID for each request and attaches it to the message. The server copies the correlation ID into the reply. The client matches replies to requests by ID.

Request message:
 correlationId: "req-abc-123"
 replyTo: "reply-queue-client-1"
 body: { action: "getPrice", productId: "SKU-456" }

Reply message:
 correlationId: "req-abc-123"
 body: { price: 29.99, currency: "USD" }

The replyTo field tells the server where to send the response. This can be:

• A shared reply queue where all clients listen and filter by correlation ID. Simpler setup, but every client sees every reply and discards non-matching ones.
• A per-client exclusive queue where each client has its own reply queue. Simpler matching (no filtering needed), but more queues to manage.

RabbitMQ's RPC tutorial uses the exclusive queue approach: each client creates an auto-delete reply queue on connect and destroys it on disconnect. Azure Service Bus supports session-based reply queues where the session ID acts as the correlation mechanism.