Request-reply

Request-reply over a broker simulates RPC with correlation IDs, reply queues or topics, and timeouts. Useful when fire-and-forget is insufficient but you still want buffering — yet it adds latency variance and harder debugging than HTTP.

Design explicit correlation, TTL on reply messages, backpressure when reply consumers lag, and fallback when the reply never arrives.

On interviews: compare message-based request-reply to gRPC for the same use case; list failure modes (orphan replies, duplicate responses).

Common pitfalls: no timeout on waiting for reply; shared reply queue without correlation; blocking threads while waiting on Kafka.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Generate and propagate correlation IDs.
• Set reply TTL and client-side timeouts.
• Make handlers idempotent for duplicate requests.
• Prefer HTTP/gRPC unless buffering truly helps.