RabbitMQ Reply Queues
RabbitMQ request-reply options using explicit callback queues or Direct Reply-To.
Jul 11, 2026
RabbitMQ request-reply sends a request with a reply-to address and a Correlation ID. The responder publishes its result to that address and copies the correlation ID into the reply.
There are two distinct reply mechanisms.
Exclusive Callback Queue
A client can declare one server-named, exclusive queue and reuse it for multiple requests on the same connection. An exclusive queue is accessible only through its declaring connection and is deleted when that connection closes.
This is a real classic queue, so it can buffer replies while the queue exists. It is still transient: it does not survive the owning connection or broker-node failure. Server-generated names avoid recovery races associated with redeclaring well-known auto-delete queue names.
Use a map from correlation ID to pending operation rather than creating one queue per request.
Direct Reply-To
Direct Reply-To does not create a queue. With AMQP 0-9-1, the requester consumes from the pseudo-queue amq.rabbitmq.reply-to in automatic acknowledgement mode and sets the same value in the request’s reply-to property. RabbitMQ routes the response directly to the requester’s channel.
Direct Reply-To provides at-most-once reply delivery:
- there is no buffer if the requester disconnects;
- replies cannot be rejected and requeued;
- the consumer and request publisher must use the connection and channel required by the client protocol;
- a timeout must lead to retry or reconciliation when losing a reply is acceptable.
Use it for transient RPC-style calls where the requester can safely retry. Do not use it when replies require durable buffering or at-least-once delivery.
Business Reliability
Neither mechanism makes the business operation exactly once. A timeout is ambiguous: the worker may not have received the request, may still be processing it, or may have completed it while the reply was lost.
Persist the operation state, make processing idempotent, and expose a way to query or reconcile the result. If the request is retried, an idempotency key should cause the responder to return the existing result rather than repeat an irreversible action.