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.