What is the request/reply (RPC) pattern in RabbitMQ?
Understand RabbitMQ's request/reply RPC pattern using reply_to and correlation_id, with working code, analogies and common interview questions.
Expected Interview Answer
The request/reply (RPC) pattern in RabbitMQ lets a client send a request message and receive a matching response asynchronously by using a reply-to queue and a correlation ID to pair the answer with the original request.
The client publishes a request carrying two properties: reply_to, naming a callback queue it consumes from, and correlation_id, a unique token. The server processes the request and publishes its response to that reply_to queue, echoing the same correlation_id. Because one callback queue may hold answers to many outstanding requests, the client uses the correlation_id to match each reply to the right pending call, turning asynchronous messaging into a request/response interaction.
- Adds request/response semantics over async messaging
- Correlation ID reliably pairs replies to requests
- Server and client stay decoupled through queues
- Load can be spread across multiple RPC workers
- Client can issue many concurrent requests on one callback queue
AI Mentor Explanation
The third-umpire referral is request/reply: the on-field umpire signals a specific review (the correlation ID) up to the booth, keeps play paused, and waits. The third umpire studies it and sends back a verdict tagged to that exact referral, so the field umpire knows which decision the answer belongs to — a request sent with a reply channel and a matching token, answered later.
Step-by-Step Explanation
Step 1
Client declares a callback queue
The client creates an exclusive reply queue it will consume responses from.
Step 2
Client sends the request
It publishes the request with reply_to set to the callback queue and a unique correlation_id.
Step 3
Server processes and responds
The server consumes the request, computes a result, and publishes it to the reply_to queue.
Step 4
Server echoes the correlation ID
The response carries the same correlation_id so it can be matched to its request.
Step 5
Client matches the reply
The client reads the callback queue and uses correlation_id to resolve the correct pending request.
What Interviewer Expects
- Explaining reply_to and correlation_id together
- Why a single callback queue needs correlation IDs
- How RPC stays asynchronous under the hood
- Handling multiple concurrent outstanding requests
- Awareness of timeouts and failed/dead servers
Common Mistakes
- Omitting correlation_id and mismatching replies
- Creating a new callback queue per request wastefully
- Assuming RPC is synchronous inside the broker
- Ignoring timeouts when the server never replies
- Forgetting the server must echo the correlation_id
Best Answer (HR Friendly)
“Request/reply in RabbitMQ is like ordering with a buzzer: you send a request with a return address and a unique number, keep doing other things, and when the answer comes back with that same number you know it's the reply to your request. It gives you a question-and-answer flow over asynchronous messages.”
Code Example
const ch = await conn.createChannel()
const { queue: replyTo } = await ch.assertQueue('', { exclusive: true })
const correlationId = crypto.randomUUID()
ch.consume(replyTo, (msg) => {
if (msg.properties.correlationId === correlationId) {
console.log('Result:', msg.content.toString())
}
}, { noAck: true })
ch.sendToQueue('rpc_queue', Buffer.from('7'), { correlationId, replyTo })ch.consume('rpc_queue', (msg) => {
const n = parseInt(msg.content.toString(), 10)
const result = String(n * n)
ch.sendToQueue(msg.properties.replyTo, Buffer.from(result), {
correlationId: msg.properties.correlationId,
})
ch.ack(msg)
})Follow-up Questions
- Why is a correlation ID necessary if each request had its own queue?
- How do you implement a timeout when the server never replies?
- How can you scale RPC across multiple worker servers?
- What are the trade-offs of RPC versus event-driven messaging?
- How would you handle a poisoned request that always fails?
MCQ Practice
1. Which message property tells the RPC server where to send its response?
The reply_to property names the callback queue the client is consuming, so the server knows where to publish the response.
2. What is the purpose of the correlation_id in RabbitMQ RPC?
A single callback queue may receive many replies, so the correlation_id lets the client pair each reply with the correct pending request.
3. Why is RabbitMQ RPC still considered asynchronous?
Requests and replies travel as independent messages through queues; the client is free to do other work while awaiting the response.
Flash Cards
What two properties power RabbitMQ RPC? — reply_to (callback queue) and correlation_id (matches reply to request).
Why is correlation_id needed? — One callback queue can hold many replies; the ID pairs each with the right request.
Where does the server send its response? — To the queue named in the request's reply_to property.
Is RabbitMQ RPC synchronous? — No — it layers request/response semantics over asynchronous queue messaging.