Request-reply pattern in RabbitMQ - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the Request-reply pattern in RabbitMQ?

It is a messaging pattern where a client sends a request message to a server and waits for a reply message. The server processes the request and sends back a response.

beginner

Which RabbitMQ feature helps correlate requests and replies in the Request-reply pattern?

The correlation_id property is used to match replies to their original requests.

beginner

What is the purpose of the reply_to property in RabbitMQ messages?

It tells the server where to send the reply message, usually the queue name where the client listens for responses.

intermediate

Why should the reply queue in the Request-reply pattern be exclusive and auto-delete?

To ensure the reply queue is private to the client and is deleted automatically when the client disconnects, avoiding leftover queues.

intermediate

How does the client know which reply message corresponds to its request in RabbitMQ?

By checking the correlation_id in the reply message and matching it with the correlation_id sent in the request.

In RabbitMQ's Request-reply pattern, what does the reply_to property specify?

A The message priority

B The exchange to publish the request

C The routing key for the request

D The queue where the reply should be sent

The reply_to property tells the server which queue to send the reply message to.

What is the role of correlation_id in the Request-reply pattern?

A To match replies with their original requests

B To specify the reply queue name

C To set message expiration time

D To identify the client application

correlation_id helps the client match the reply message to the request it sent.

Why is it recommended to use an exclusive, auto-delete queue for replies?

A To ensure the reply queue is private and removed when no longer needed

B To keep the reply queue persistent after client disconnects

C To allow multiple clients to share the reply queue

D To increase message throughput

Exclusive, auto-delete queues are private to the client and are deleted automatically when the client disconnects.

In the Request-reply pattern, what does the client do after sending a request?

A It immediately closes the connection

B It waits and listens on the reply queue for the response

C It sends the reply to the server

D It deletes the request message

The client listens on the reply queue to receive the server's response.

Which RabbitMQ component is typically used to send requests in the Request-reply pattern?

A Exchange

B Binding

C Channel

D Queue

A channel is used by the client to publish request messages to an exchange or queue.

Explain how the Request-reply pattern works in RabbitMQ, including the roles of reply_to and correlation_id.

Think about how the client and server communicate back and forth using queues and message properties.

Describe why using an exclusive, auto-delete reply queue is important in the Request-reply pattern.

Consider what happens if reply queues stay after clients disconnect.

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