Request-reply pattern in RabbitMQ - Commands & Configuration

Introduction

Sometimes, one program needs to ask another program for information and wait for the answer. The request-reply pattern helps programs send a question and get a reply back using RabbitMQ messaging.

When a web app needs to ask a backend service for data and wait for the answer before showing it to the user.

When a microservice needs to request processing from another microservice and wait for the result.

When a client program sends a task to a server and needs to know when the task is done.

When you want to keep programs loosely connected but still need answers to specific questions.

When you want to avoid blocking the whole system but still get replies for important requests.

Config File - request_reply_setup.py

request_reply_setup.py

import pika

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

channel.queue_declare(queue='rpc_queue')

print('RPC queue declared and ready')

connection.close()

This Python script connects to RabbitMQ on localhost and declares a queue named rpc_queue. This queue will receive request messages. Declaring the queue ensures it exists before sending or receiving messages.

Commands

Run the setup script to create the RPC queue where requests will be sent.

Terminal

python request_reply_setup.py

Expected Output

RPC queue declared and ready

Check that the queue named rpc_queue exists and is ready to receive messages.

Terminal

rabbitmqctl list_queues

Expected Output

Listing queues ...

rpc_queue	0

Start the RPC server that listens on rpc_queue, processes requests, and sends replies back.

Terminal

python rpc_server.py

Expected Output

 [x] Awaiting RPC requests

Run the RPC client that sends a request message to rpc_queue and waits for the reply from the server.

Terminal

python rpc_client.py

Expected Output

 [.] Requesting fib(6)

 [.] Got 8

Key Concept

If you remember nothing else from this pattern, remember: the client sends a request message with a unique reply queue and waits for the server to send the answer back to that queue.

Common Mistakes

Not setting a unique reply queue or correlation ID in the request message.

Without a unique reply queue or correlation ID, the client cannot match replies to its requests, causing confusion or lost responses.

Always set a unique reply queue and a correlation ID in the request message properties to track replies properly.

Not declaring the queue before sending or receiving messages.

If the queue does not exist, messages will be lost or cause errors.

Declare the queue on both client and server sides before using it.

Blocking the server without acknowledging messages.

The server may stop processing new requests if it does not acknowledge completed messages.

Acknowledge each request message after processing to keep the queue flowing.

Summary

Declare a queue to receive request messages.

Run a server that listens on the queue, processes requests, and sends replies.

Run a client that sends requests with a reply queue and waits for answers.

Use unique reply queues and correlation IDs to match requests and replies.

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