> В каких случаях лучше использовать брокер сообщений для взаимодействия между сервисами (Go)

Уровень: senior · Роль: backend · Язык: Go · Категория: Технические вопросы

Компании: Wildberries

Стек: Go

> Пример ответа

Брокер сообщений (например, RabbitMQ, Kafka, NATS) стоит использовать, когда требуется асинхронное, слабосвязанное и масштабируемое взаимодействие между сервисами. В Go это особенно актуально из-за легковесных горутин и каналов, которые хорошо сочетаются с очередями.

Основные сценарии:

Разделение по времени - когда сервис-отправитель не может ждать ответа от получателя (например, отправка email после регистрации пользователя). Брокер берёт сообщение, а получатель обрабатывает его позже.
Балансировка нагрузки - несколько экземпляров одного сервиса (например, обработчиков заказов) читают из одной очереди. Брокер распределяет сообщения между ними, упрощая горизонтальное масштабирование.
Обеспечение надёжности - если получатель временно недоступен, сообщение сохраняется в очереди и будет доставлено после восстановления. В Go это спасает от потери данных при падении подов.
Транзакции с компенсацией (Saga) - для распределённых транзакций, где шаги выполняются асинхронно, а сбой компенсируется отдельными сообщениями.
Потоковая обработка событий - когда нужно транслировать одно событие многим подписчикам (например, обновление каталога товаров → кеш, поиск, аналитика). Kafka идеальна для этого.

Не используйте брокер, если:

Взаимодействие синхронное и требует немедленного ответа (тогда лучше gRPC или HTTP).
Нет потребности в отказоустойчивости и масштабировании (проще обойтись прямым вызовом).
Сложность инфраструктуры не оправдана (один монолит с горутинами может быть проще).