Request-Reply Pattern for Asynchronous Communication

#architecture #systemdesign #backend

This article was originally published on AI Study Room. For the full version with working code examples and related articles, visit the original post.

Request-Reply Pattern for Asynchronous Communication

The request-reply pattern enables asynchronous request-response communication using message queues. Unlike synchronous HTTP calls, the client sends a request message and continues processing. The response arrives later through a reply queue. This decouples the sender from the receiver in both time and space.

Architecture

The client sends a request to a request queue, including a correlation ID and a reply-to address in the message header. The server consumes from the request queue, processes the request, and sends the response to the reply-to address with the same correlation ID. The client listens on the reply queue and matches responses by correlation ID.

Temporary vs Permanent Replies

For transient responses, use temporary reply queues. The client creates a unique temporary queue per request and specifies it in the reply-to header. The queue is deleted after the response is received. This is simple and avoids queue management overhead but means lost responses if the client disconnects.

For durable responses, use permanent reply queues with one queue per client. The client maintains a correlation map to match responses to pending requests. This survives client restarts but requires queue management.

Implementation with Correlation IDs

The correlation ID is a unique identifier generated by the client. It is included in the request message header and echoed back in the response. The client uses the correlation ID to match the response with the pending request.

Generate correlation IDs with UUIDs or unique message sequence numbers. Include a client instance ID in the correlation namespace to handle multiple client instances.

Message Brokers

RabbitMQ supports the request-reply pattern natively with its RPC (Remote Procedure Call) pattern. The client creates a callback queue and includes the queue name in the reply-to property. RabbitMQ sets the correlation ID automatically.

SQS and Kafka require manual correlation ID management. Store the reply-to queue URL and correlation ID in the message attributes. The response consumer uses the correlation ID to dispatch the response to the correct handler.

Error Handling

Request-reply patterns must handle timeouts. The client should set a timeout based on expected processing time. If no response arrives within the timeout, the client can retry or fail gracefully. Monitor timeout rates to detect server issues.

Dead letter queues for request queues capture requests that cannot be processed. Monitor DLQ depth and reprocess after addressing root causes.