Premium

Request-Response

Basic System Design
≈ 2 min read

One Request Is Associated with One Response

In the Request-Response pattern, a participant sends a request and expects a response that belongs specifically to that request. This is the basic model behind many HTTP and RPC calls. 

request(id=123)  ---->
                 <----  response(for=123)

The relationship seems obvious with one synchronous connection: the response arrives in the same call. But the idea itself is broader than a specific protocol and can even be implemented on top of messaging.

An Asynchronous Environment Needs a Correlation ID

If the request and response travel as separate messages, they must be linked explicitly. The request receives a correlation identifier, and the response returns the same identifier. 

{
  "type": "PRICE_REQUEST",
  "correlationId": "req-123",
  "productId": 42
}

Using correlationId, the response receiver knows which pending operation can be completed. Without such a key, several parallel requests would be hard to match with their results.

Waiting Must Have a Limit

A response may never arrive: a service can stop, a message can become irrelevant, or processing can take too long. That is why waiting needs a timeout or another completion criterion, after which the system treats the operation as failed or continues with a fallback path.

Request-Response describes the shape of the conversation, not the transport. It can be implemented with a regular HTTP call, RPC, or a pair of messages through a broker.
Back Next