Request-reply pattern in RabbitMQ - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the Request-Reply Pattern in RabbitMQ

In RabbitMQ's request-reply pattern, what is the main role of the reply_to property in a message?

A It sets the message priority for the request.

B It defines the routing key for the request message.

C It specifies the queue where the reply should be sent.

D It indicates the expiration time of the message.

💡 Hint

Think about how the requester knows where to get the response.

The reply_to property tells the consumer where to send the response message, enabling the request-reply communication.

💻 Command Output

intermediate

Output of a Basic Request-Reply Setup

Given a RabbitMQ setup where a client sends a request message with reply_to set to amq.rabbitmq.reply-to and waits for a response, what will be the output if the server replies with Hello, Client!?

RabbitMQ

Client sends request with reply_to='amq.rabbitmq.reply-to'
Server receives request and sends back 'Hello, Client!' to the reply_to queue
Client consumes message from reply_to queue

A Client receives the original request message again.

B Client receives an empty message with no content.

C Client receives an error indicating no reply queue found.

D Client receives 'Hello, Client!' as the response message.

💡 Hint

The server sends the reply to the queue specified in reply_to.

The client gets the exact reply message sent by the server on the reply queue it specified.

❓ Configuration

advanced

Configuring a Temporary Reply Queue

Which RabbitMQ queue configuration is best suited for a temporary reply queue in a request-reply pattern?

A Declare a queue with <code>durable=true</code> and <code>exclusive=false</code>.

B Declare a queue with <code>exclusive=true</code> and <code>autoDelete=true</code>.

C Declare a queue with <code>autoDelete=false</code> and <code>durable=false</code>.

D Declare a queue with <code>exclusive=false</code> and <code>autoDelete=false</code>.

💡 Hint

Think about a queue that only the client uses and disappears after use.

Temporary reply queues should be exclusive to the client and auto-delete when the client disconnects to avoid leftover queues.

❓ Troubleshoot

advanced

Troubleshooting Missing Replies

A client sends a request with reply_to set to a temporary queue, but never receives a reply. Which of the following is the most likely cause?

A The server did not send a message to the queue named in <code>reply_to</code>.

B The client queue was declared as durable instead of exclusive.

C The client did not set the <code>correlation_id</code> property.

D The server used the wrong exchange to send the request.

💡 Hint

Check if the server actually sent the reply to the correct queue.

If the server does not send the reply to the queue specified in reply_to, the client will never receive it.

🔀 Workflow

expert

Correct Sequence of Steps in Request-Reply Pattern

What is the correct order of steps in a RabbitMQ request-reply pattern?

A 1,2,3,4,5

B 2,1,3,4,5

C 1,3,2,4,5

D 1,2,4,3,5

💡 Hint

Think about what the client must do before sending the request.

The client must first create the reply queue, then send the request with reply_to set, the server processes and replies, and finally the client consumes the reply.

Practice

1.

What is the main purpose of the reply_to property in RabbitMQ's request-reply pattern?

easy

A. It identifies the sender of the request message.

B. It tells the receiver where to send the reply message.

C. It encrypts the message content for security.

D. It sets the priority of the message in the queue.

Solution

1. Step 1: Understand the role of reply_to

   The reply_to property specifies the queue where the reply should be sent.

2. Step 2: Differentiate from other properties

   Unlike sender identification or encryption, reply_to directs the response path.

3. Final Answer:

   It tells the receiver where to send the reply message. -> Option B

4. Quick Check:

   reply_to = reply destination [OK]

Hint: Remember: reply_to points to the reply queue [OK]

Common Mistakes:

• Confusing reply_to with sender ID
• Thinking reply_to sets message priority
• Assuming reply_to encrypts messages

2.

Which of the following is the correct way to set the correlation_id in a RabbitMQ message using Python pika library?

channel.basic_publish(exchange='', routing_key='rpc_queue', properties=..., body='Hello')

easy

A. properties=pika.BasicProperties(correlationId='12345')

B. properties=pika.BasicProperties(correlation='12345')

C. properties=pika.BasicProperties(corr_id='12345')

D. properties=pika.BasicProperties(correlation_id='12345')

Solution

1. Step 1: Recall correct property name

   The correct property name for correlation is correlation_id in pika.BasicProperties.

2. Step 2: Match syntax exactly

   properties=pika.BasicProperties(correlation_id='12345') uses the exact correct syntax: correlation_id='12345'.

3. Final Answer:

   properties=pika.BasicProperties(correlation_id='12345') -> Option D

4. Quick Check:

   Correct property name = correlation_id [OK]

Hint: Use exact property names from docs: correlation_id [OK]

Common Mistakes:

• Using incorrect property names like correlation or corr_id
• Capitalizing property names incorrectly
• Omitting properties argument

3.

Given this Python code snippet using pika for request-reply, what will be printed?

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

channel.queue_declare(queue='rpc_queue')

corr_id = 'abc123'

channel.basic_publish(
    exchange='',
    routing_key='rpc_queue',
    properties=pika.BasicProperties(reply_to='reply_queue', correlation_id=corr_id),
    body='Request')

print(corr_id)

medium

A. abc123

B. Request

C. reply_queue

D. Error: missing callback

Solution

1. Step 1: Identify what is printed

   The code prints the variable corr_id which is set to 'abc123'.

2. Step 2: Understand message sending vs printing

   Sending a message does not affect the print statement; it prints the variable value.

3. Final Answer:

   abc123 -> Option A

4. Quick Check:

   Printed variable = corr_id = abc123 [OK]

Hint: Print shows variable, not message content or errors [OK]

Common Mistakes:

• Confusing printed output with message body
• Expecting error due to missing reply handler
• Thinking reply_to value is printed

4.

In a request-reply setup, a developer notices replies never arrive. Which fix addresses this common error?

channel.basic_publish(exchange='', routing_key='rpc_queue', properties=pika.BasicProperties(), body='Hello')

medium

A. Remove exchange parameter completely.

B. Change routing_key to reply_queue.

C. Add reply_to and correlation_id in properties.

D. Set body to empty string.

Solution

1. Step 1: Identify missing properties

   The message lacks reply_to and correlation_id, needed for replies.

2. Step 2: Add these properties to enable reply routing

   Including reply_to tells where to send replies; correlation_id matches responses.

3. Final Answer:

   Add reply_to and correlation_id in properties. -> Option C

4. Quick Check:

   Missing reply_to/correlation_id blocks replies [OK]

Hint: Always set reply_to and correlation_id for replies [OK]

Common Mistakes:

• Changing routing_key instead of adding properties
• Removing exchange causes unrelated errors
• Setting empty body does not fix reply issues

5.

You want to implement a request-reply pattern where multiple clients send requests and receive replies without mixing responses. Which approach ensures correct matching?

hard

A. Use a unique correlation_id per request and a shared reply queue.

B. Use the same correlation_id for all requests and separate reply queues.

C. Use unique correlation_id per client and unique reply queues per client.

D. Use no correlation_id and a shared reply queue.

Solution

1. Step 1: Understand correlation_id role

   A unique correlation_id lets clients match replies to requests even on a shared reply queue.

2. Step 2: Evaluate reply queue usage

   Using a shared reply queue with unique IDs is efficient and common practice.

3. Final Answer:

   Use a unique correlation_id per request and a shared reply queue. -> Option A

4. Quick Check:

   Unique correlation_id + shared queue = correct matching [OK]

Hint: Unique correlation_id with shared reply queue avoids mix-ups [OK]

Common Mistakes:

• Using same correlation_id causes reply confusion
• Creating many reply queues adds complexity
• Omitting correlation_id breaks matching