How to handle request‐response communication with message queues? - rnakidi/dsa GitHub Wiki
“How to handle request-response communication with message queues?”
First of all, we need to understand why this is needed.
With a message queue, you can let two services talk to each other (request-response) asynchronously.
This approach is quite important for long-running tasks. Also, no synchronous calls means less chance of a single service bringing down the application.
But there is a problem.
👉 What if there are multiple requester and responder instances?
This doesn’t matter much in a synchronous REST API call because one requester instance always connects to just one responder instance. There is a temporal coupling.
Not the case with async request-response.
The requester instance that made the request may not be the one that ultimately receives the response. It may be down or unavailable by the time the response comes back.
👉 So - how do you relate a request and response across multiple ephemeral instances?
One common way is to use a correlation ID. Here’s how it works:
✅ Suppose there is an Order Service and Payment Service that interact in an async request-reply model.
✅ A customer places an order through one instance of the Order Service. It generates a unique correlation ID for this order, storing the corresponding data in a database, distributed cache, or even a local instance-level HashMap.
✅ Next, it sends a payment request message to the Payment Service along with the correlation ID.
✅The Payment Service (a particular instance) processes the payment and sends the response to the reply queue. The response message contains the same correlation ID.
✅ The Order Service (same or another instance) picks up the response message. It uses the correlation ID in the message to match the response to the original order request and takes the necessary action.
At this point, you may ask question the need for correlation ID. The same can be accomplished with the order ID.
True, but there are some benefits:
-
Multiple payment requests can be sent for the same order (retries, partial payments, etc). A unique correlation ID/request helps match them properly.
-
The correlation ID separates the routing logic from the business context (like Order ID).
-
Correlation IDs make it easy to trace the flow of the request across multiple services.