Correlation ID for matching replies in RabbitMQ - Commands & Configuration

Introduction

When you send a message and expect a reply, you need a way to know which reply matches which request. Correlation ID is a unique tag added to messages to link requests with their responses. This helps keep conversations clear and organized.

When your application sends multiple requests and needs to match each reply to the correct request.

When you use RabbitMQ for RPC (Remote Procedure Call) style communication between services.

When you want to track message flow in asynchronous systems to debug or log interactions.

When multiple clients share the same reply queue and you need to separate their responses.

When you want to avoid mixing up replies in a system handling many simultaneous messages.

Commands

This command sends a message with a correlation ID '12345' and specifies 'reply_queue' as the queue to receive the reply. The correlation ID helps match the reply to this request.

Terminal

rabbitmqadmin publish exchange=amq.direct routing_key=request_queue properties='{"correlation_id":"12345", "reply_to":"reply_queue"}' payload='Hello'

Expected Output

Message published

→

properties - Sets message properties like correlation_id and reply_to

This command fetches one message from the reply queue. You check the correlation ID in the message properties to find which request this reply belongs to.

Terminal

rabbitmqadmin get queue=reply_queue count=1

Expected Output

Message 1:

  payload: 'Hello response'

  properties:

    correlation_id: '12345'

    reply_to: ''

→

count - Number of messages to retrieve

Key Concept

If you remember nothing else from this pattern, remember: correlation ID links each reply to its original request so you can match them correctly.

Common Mistakes

Not setting the correlation_id property when sending a request.

Without correlation_id, replies cannot be matched to requests, causing confusion and errors.

Always set a unique correlation_id for each request message.

Using the same correlation_id for multiple requests simultaneously.

Replies will be mixed up because the correlation ID is not unique per request.

Generate a unique correlation_id for every request to avoid collisions.

Ignoring the reply_to property and not specifying where replies should be sent.

Replies may go to the wrong queue or get lost, making matching impossible.

Set the reply_to property to the queue where you want to receive replies.

Summary

Send messages with a unique correlation_id and reply_to queue to track replies.

Fetch replies from the reply queue and check their correlation_id to match requests.

Always generate unique correlation IDs and specify reply queues to avoid confusion.