advanced

Request-reply

Используйте request-reply over messaging только когда correlation IDs, timeouts, backpressure и user-visible latency explicitly handled.

Request-reply через broker имитирует RPC с correlation IDs, reply queues или topics и timeouts. Полезно, когда fire-and-forget недостаточно, но нужен buffering — однако добавляет latency variance и сложнее debugging, чем HTTP.

Проектируйте явную correlation, TTL на reply messages, backpressure при отставании reply consumers и fallback, если reply не пришёл.

На интервью: сравните message-based request-reply с gRPC для того же кейса; перечислите failure modes (orphan replies, duplicate responses).

Типовые ошибки: нет timeout при ожидании reply; shared reply queue без correlation; blocking threads при ожидании на Kafka.

Компромисс — гибкость против сложности: знайте, когда достаточно более простого пути.

Чеклист:

  • Генерируйте и распространяйте correlation IDs.
  • Задайте reply TTL и client-side timeouts.
  • Делайте handlers idempotent для duplicate requests.
  • Предпочитайте HTTP/gRPC, пока buffering реально не нужен.