Представим, что после оформления заказа нужно обновить склад, отправить уведомление, передать данные в аналитику и запустить ещё несколько процессов. Самый очевидный путь — вызвать каждую систему напрямую.
Пока потребителей мало, это работает. Но со временем отправитель начинает знать слишком много о том, кто и как должен обработать событие.
Какую проблему мы решаем
Message broker — очередь или платформа обмена сообщениями — становится посредником. Отправитель публикует событие или сообщение, а получатели забирают его независимо.
Конкретные технологии могут сильно отличаться. Для архитектурного решения важнее другое: отправитель больше не обязан ждать каждого потребителя и знать их внутреннее устройство.
Что получает бизнес
Главная выгода — дешевле добавлять новые реакции на уже существующие события. Если завтра после заказа нужно запускать ещё один процесс, не всегда требуется менять сам сервис заказа.
Брокер также помогает переживать пики. Если потребитель временно не успевает обработать поток, сообщения могут накапливаться вместо немедленного отказа всего процесса.
Это создаёт возможность масштабировать части бизнеса независимо. Один процесс может быть медленнее другого, не заставляя всю цепочку работать с одинаковой скоростью.
Что получает команда
Команды получают более слабую связанность между системами и понятный способ строить асинхронные процессы.
Но появляется новая инженерная работа: повторная доставка, порядок сообщений, дедупликация, обработка ошибок, наблюдаемость очередей и управление схемами сообщений.
Что получает клиент
Клиент может получить более устойчивый основной сценарий. Например, временная проблема в аналитике не обязана блокировать оформление заказа.
Но асинхронность означает, что часть результатов появляется не мгновенно. Статус в одной системе может обновиться чуть позже другой, и это нужно учитывать в интерфейсе и ожиданиях пользователя.
Чем мы за это платим
Брокер — ещё один критичный инфраструктурный компонент. Его нужно разворачивать, масштабировать, мониторить и восстанавливать.
Сложнее становится и сам поток данных. При прямом вызове легко увидеть: сервис A вызвал сервис B. При очередях событие может пройти через несколько потребителей и повторных обработок.
Поэтому message broker покупает гибкость не бесплатно. Компания меняет связанность между приложениями на сложность асинхронной инфраструктуры.
Когда брокер не нужен
Если взаимодействие простое, синхронное и результат нужен сразу, обычный API часто лучше. Особенно если систем мало и нагрузка предсказуема.
Не стоит добавлять очередь только потому, что архитектура «должна быть event-driven».
Что стоит спросить перед решением
- Нужно ли отправителю ждать результат прямо сейчас?
- Сколько независимых потребителей будет у события?
- Что произойдёт, если один из них временно недоступен?
- Допустима ли повторная доставка сообщения?
- Кто отвечает за схему события и её совместимость?
В итоге
Message broker полезен не потому, что очереди современнее прямых вызовов. Он полезен, когда бизнесу действительно нужна независимость между скоростью отправителя и скоростью получателей.
Мы выигрываем в гибкости и устойчивости, но платим более сложным поведением системы, которое нужно уметь видеть и контролировать.