Можно ли использовать брокер как маршрутизатор при синхронном взаимодействии двух систем?

Можно ли использовать брокер как маршрутизатор при синхронном взаимодействии

Это хороший архитектурный вопрос. Технически — можно, но это обычно плохая идея. Давайте разберёмся почему.

Что такое брокер и его назначение

Брокер сообщений (Message Broker) — это промежуточное ПО, которое собирает сообщения от отправителя и доставляет их получателю. Примеры:

• RabbitMQ
• Apache Kafka
• AWS SQS/SNS
• Azure Service Bus

Его основное назначение — асинхронное взаимодействие:

• Отправитель кидает сообщение в очередь и не ждёт
• Получатель забирает его когда готов
• Если получатель упал, сообщение остаётся в очереди

Синхронное взаимодействие через брокер: теория

Теоретически, можно реализовать синхронный паттерн через брокер:

1. System A отправляет запрос в брокер
2. System B получает запрос из брокера
3. System B отправляет ответ в отдельную очередь (reply-to)
4. System A ждёт ответа в этой очереди

Пример с RabbitMQ:

# System A (Request)
import pika
import uuid
import time

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

# Создаём очередь для ответов
reply_queue = channel.queue_declare(queue='', exclusive=True).method.queue
corr_id = str(uuid.uuid4())

# Отправляем запрос
channel.basic_publish(
    exchange='',
    routing_key='request_queue',
    body='get_user_info',
    properties=pika.BasicProperties(
        reply_to=reply_queue,
        correlation_id=corr_id
    )
)

# Ждём ответ (СИНХРОННО)
response = None
def on_response(ch, method, props, body):
    if props.correlation_id == corr_id:
        global response
        response = body

channel.basic_consume(queue=reply_queue, on_message_callback=on_response)

while response is None:
    channel.connection.process_data_events()
    time.sleep(0.1)  # Polling

print(f"Ответ получен: {response}")

Да, это работает. Но...

Почему это плохая идея

1. Потеря главного преимущества асинхронности

• Смысл брокера в том, что отправитель не блокируется
• Если мы ждём ответ синхронно, то это просто обычный HTTP запрос, но через брокер
• Мы добавили задержку и сложность, но теряем reliability

2. Сложность и latency

• HTTP запрос: System A → System B → ответ (несколько мс)
• RabbitMQ: System A → очередь → брокер → очередь → System B → очередь → ответ → очередь → System A (100+ мс)
• Брокер добавляет сетевые вызовы и диск (если persistent)

3. Timeouts и失败сценарии

• Если System B не может ответить, System A зависнет
• Нет встроенных механизмов timeout (нужно писать вручную)
• Сложнее обрабатывать ошибки и retry логику

4. Масштабируемость

• Если много System A ждут ответов одновременно, брокер может стать узким местом
• HTTP с connection pooling работает лучше

5. Отладка

• Очень сложно дебажить: сообщение прошло? Потеряется где-то? Ответ где?
• HTTP с логированием намного прозрачнее

Когда всё же использовать брокер для синхронного паттерна

Исключения есть, но редко:

1. Обходной способ авторизации

• System A не может напрямую подключиться к System B (firewall)
• Оба могут подключиться к брокеру
• Используем брокер как "почту" для синхронного запроса

2. Load balancing через несколько workers

• Много System B инстансов слушают одну очередь
• Запрос автоматически идёт на свободный инстанс
• (Но это можно сделать проще с обычным load balancer)

3. Очень временные сбои

• System B иногда недоступна
• Хотим положить запрос в очередь и пробовать позже
• (Но лучше использовать HTTP с retry логикой)

Правильные паттерны взаимодействия

Синхронное: используй HTTP / REST / gRPC

System A --[HTTP запрос]--> System B
         <--[ответ]--

• Быстро
• Просто
• Встроена обработка ошибок

Асинхронное: используй брокер

System A --[сообщение]--> Брокер --[сообщение]--> System B

• Независимость
• Reliability
• Scaling

Реальный пример из практики

Одна компания попыталась сделать синхронное взаимодействие через RabbitMQ. Результат:

• P99 latency был 5 секунд (вместо 100 мс через HTTP)
• Много потерянных запросов при перезагрузке брокера
• Разработчики потратили месяц на отладку

Решение: переписали на HTTP + Kafka для асинхронного логирования событий.

Мой совет

Правило:

• Если System A ждёт ответа → используй HTTP/gRPC
• Если System A не ждёт ответа → используй брокер

Если требуется синхронное взаимодействие, но есть проблемы с доступностью, решай эти проблемы (VPN, API Gateway), а не усложняй архитектуру брокером.

Брокер — инструмент для асинхронности. Использовать его для синхронности — это всё равно что использовать молоток вместо отвёртки. Технически может сработать, но это неправильный инструмент.