Back to Catalog
Integration
Message Construction
Request-Reply
Need a response? Send a request message, wait for the reply on a dedicated channel.
Intent & Description
Real-world Use Case
Price calculation service — Order Service sends a PriceRequest message, includes its private reply queue address and a correlation ID. Pricing Service calculates and sends PriceResponse to the reply queue. Order Service matches it via correlation ID.
Source
📌 TL;DR
Request-Reply = async ping-pong over a message broker. You ask, they answer, you match via correlation ID. More moving parts than HTTP, but messaging resilience included.
Advantages
- Response semantics over messaging — get answers without sync HTTP
- Messaging benefits preserved — buffering, retry, broker persistence
- Supports async processing — requester can do other work while waiting
- Works across different tech stacks and languages
Disadvantages
- More complex than a plain REST call — needs correlation IDs, reply channels
- Latency is typically higher than direct HTTP due to broker hops
- Timeout management adds complexity
- Reply channels can proliferate and need lifecycle management