Система заказов отдала сообщение в брокер и получила подтверждение. Звучит как успех. Но склад ещё не создал задачу на сборку, а в службе поддержки клиент уже спрашивает, где его покупка. Подтверждение приёма сообщения не равно выполненному бизнес-действию.
Message Broker нужен там, где отправитель и получатель должны работать с разной скоростью или быть временно недоступны друг другу. Он уменьшает прямую связанность, но не делает весь процесс автоматом надёжным.
Какая проблема исчезает
При прямом вызове система заказов ждёт ответа склада. Если склад недоступен, вызов заканчивается ошибкой или ожиданием. Через брокер сервис может положить сообщение в надёжный транспорт, а склад обработает его позже.
Это особенно полезно при всплесках нагрузки: очередь позволяет принять работу быстрее, чем отдельный потребитель способен её выполнить. Но если сообщений постоянно поступает больше, чем обрабатывается, очередь не решает проблему мощности. Она лишь делает отставание видимым — при условии, что его измеряют.
Очередь и рассылка событий — разные соглашения
Команда «собери этот заказ» адресована исполнителю. Часто её должен выполнить один из работников группы. Событие «заказ подтверждён» могут независимо получить уведомления, склад и аналитика. Конкретные модели очередей и publish/subscribe отличаются в правилах хранения и доставки, поэтому их не стоит называть взаимозаменяемыми.
Перед выбором продукта важно ответить, кто является владельцем работы, сколько получателей должно обработать сообщение и сколько времени данные необходимо хранить для повторной обработки.
Что брокер не гарантирует сам
Получатель может упасть после выполнения операции, но до подтверждения обработки. Тогда сообщение придёт повторно. Бывают задержки, ошибки обработки и нарушение ожидаемого порядка. Правила зависят от транспорта, однако бизнес-операция в любом случае должна быть безопасна к повторам там, где они возможны.
Для сообщений, которые нельзя обработать после нескольких попыток, может понадобиться Dead Letter Queue. Но помещённое туда сообщение — не выполненный заказ. Нужен владелец, который увидит исключение и решит, как продолжать.
Есть ещё маленькая, но дорогая щель: запись в базу успешно сделана, а публикация сообщения провалилась. Для неё существует Transactional Outbox. Брокер сам по себе не закрывает эту проблему.
Где появляется экономическая цена
Брокер требует мониторинга, политик повторов, версий контрактов и планов на длительную недоступность потребителя. У команды появляется отдельная компетенция и круглосуточная ответственность за очереди, в которых лежат реальные клиентские обещания.
Я бы спрашивал не «сколько сообщений мы обрабатываем», а «сколько бизнес-операций сейчас не закончено, как давно и кто отвечает за восстановление». Быстрый брокер с тысячами зависших заказов — сомнительное достижение.
Брокер оправдан, когда разрыв по времени и нагрузке между системами действительно мешает продукту. Он переносит ответственность за завершение работы, но не отменяет её.