Request-Reply Pattern

Why Request-Reply Over Messaging?

Most inter-service communication in microservices is synchronous: service A calls service B and waits for an answer. Normally this is done with HTTP/gRPC. But sometimes you want to route these request-response interactions through a message broker — so you get broker benefits (durability, routing, retries) while still maintaining the call-and-response semantics the caller needs.

The Request-Reply pattern achieves this by having the requester publish a message to a request queue and wait for a response message on a dedicated reply queue. A correlation ID ties the response back to the original request. This is sometimes called the RPC over messaging pattern.

Pattern Flow

Correlation ID

The correlation ID is a UUID (or similar unique token) generated by the requester when sending a message. It is echoed back verbatim by the responder in its reply. The requester maintains a map of `correlationId → pending promise/callback` and uses the correlation ID from the incoming reply to resolve the right waiter.

// Requester side — simplified
const pending = new Map<string, (result: unknown) => void>();

async function sendRequest(payload: unknown): Promise<unknown> {
  const correlationId = crypto.randomUUID();
  const replyTo = "replies.service-a." + correlationId;

  return new Promise((resolve) => {
    pending.set(correlationId, resolve);

    broker.publish("requests.service-b", {
      correlationId,
      replyTo,
      payload,
    });

    // Timeout guard — don't wait forever
    setTimeout(() => {
      if (pending.has(correlationId)) {
        pending.delete(correlationId);
        resolve({ error: "timeout" });
      }
    }, 5000);
  });
}

// On incoming reply from reply queue:
broker.subscribe(myReplyQueue, (msg) => {
  const resolve = pending.get(msg.correlationId);
  if (resolve) {
    pending.delete(msg.correlationId);
    resolve(msg.payload);
  }
});

Reply Queue Strategies

There are two common strategies for reply queues:

Timeouts Are Non-Negotiable

Unlike HTTP where a closed connection signals failure, a request waiting for a reply on a queue has no inherent signal that the responder died. You must implement a client-side timeout. Without it, your `pending` map will grow unbounded and your callers will block indefinitely. Choose timeouts based on P99 processing latency of the responder plus a safety margin — typically 2–5x the expected response time.

Request-Reply vs Fire-and-Forget