Request-Reply over Queues

Overview

Request-reply layers a conversation on one-way messaging. Each side needs only the broker, not the other side address.

The correlation id is the essential piece. Without it a requester with many in-flight calls cannot tell which reply is which.

Decide how the caller experiences the wait. A synchronous wrapper blocks until the reply or timeout, which is convenient but ties up a thread. An asynchronous style returns a ticket at once and delivers the result by callback, polling endpoint or notification, which scales better for slow work.

How it works

The requester registers a pending entry under a fresh correlation id, publishes the request, and a reply listener completes the entry when a matching reply arrives.

req  = {id: "c-91", replyTo: "replies.svcA", body: ...}
send("pricing.requests", req)

# responder
send(req.replyTo, {id: req.id, result: ...})

# requester listener
pending.pop("c-91").complete(result)

On the responder side, check the expiry before starting, since a request that waited in a long queue may already be useless. For idempotency, key the response by correlation id so a redelivered request returns the same answer instead of redoing the work. Include an error reply shape so failures arrive as messages rather than as silent timeouts.

Pitfalls

• Unbounded waits instead of timeouts with a clear failure path.
• Creating a new temporary queue per request, which is expensive at volume; use one per instance.
• Ignoring late replies instead of discarding them by correlation id.
• Not setting message TTL, so dead requesters leave work behind.

Key takeaways

• Correlation id plus reply-to address define the pattern.
• Always set a timeout and a message expiry.
• Prefer one reply queue per instance.
• Handle late and duplicate replies gracefully.