Why RPC enables request-reply over queues in RabbitMQ - Why It Works

Introduction

When two programs need to talk and get answers, they can use queues to send messages. RPC helps by making one program ask a question and wait for the answer, even though messages travel through queues.

When a service needs to ask another service for data and wait for the answer.

When you want to split a big task into smaller parts and get results back from each part.

When you want to keep programs separate but still let them communicate clearly.

When you want to avoid programs waiting too long by using queues but still get replies.

When you want to build a simple chat between two programs using message queues.

Commands

This command creates a new user named rpc_user with password rpc_password to allow secure access to RabbitMQ for RPC communication.

Terminal

rabbitmqctl add_user rpc_user rpc_password

Expected Output

Adding user "rpc_user" ...

This command gives the rpc_user full permissions on the default virtual host so it can create and use queues for RPC.

Terminal

rabbitmqctl set_permissions -p / rpc_user ".*" ".*" ".*"

Expected Output

Setting permissions for user "rpc_user" in vhost "/" ...

This command creates a queue named rpc_queue where the client will send requests and the server will listen for them.

Terminal

rabbitmqadmin declare queue name=rpc_queue durable=false

Expected Output

Queue declared

This command creates a reply_queue where the server will send back answers to the client.

Terminal

rabbitmqadmin declare queue name=reply_queue durable=false

Expected Output

Queue declared

This command sends a request message to rpc_queue asking to sum 5 and 3. It includes reply_to and correlation_id so the server knows where to send the answer and how to match it.

Terminal

rabbitmqadmin publish routing_key=rpc_queue payload='{"method":"sum","params":[5,3]}' properties='{"reply_to":"reply_queue","correlation_id":"12345"}'

Expected Output

Message published

Key Concept

RPC uses special message properties like reply_to and correlation_id to link requests and replies over queues, enabling clear request-reply communication.

Common Mistakes

Not setting the reply_to property in the request message

Without reply_to, the server does not know where to send the reply, so the client never gets the answer.

Always include reply_to with the client's reply queue name in the request message properties.

Not using correlation_id to match replies to requests

If multiple requests are sent, replies can get mixed up without correlation_id, causing confusion in the client.

Set a unique correlation_id for each request and check it in the reply to match responses correctly.

Using durable queues without proper message acknowledgment

Durable queues keep messages but if acknowledgments are missing, messages can be lost or duplicated.

Use non-durable queues for simple RPC or implement acknowledgments properly for durable queues.

Summary

RPC over queues uses reply_to and correlation_id message properties to enable request-reply communication.

Clients send requests to a known queue and listen on a reply queue for answers.

Servers read requests, process them, and send replies back to the reply queue specified by the client.