В событийной архитектуре часто нужно сделать две вещи: изменить данные и сообщить об этом другим системам.
Например, создать заказ в базе и отправить событие OrderCreated. Проблема в том, что это две разные операции.
Если база уже сохранила заказ, а брокер сообщений в этот момент недоступен, появляется неприятное состояние: факт есть, события нет.
Какую проблему мы решаем
Outbox Pattern предлагает сохранять бизнес-изменение и запись о будущем событии в одной локальной транзакции базы данных.
Отдельный процесс затем читает outbox и отправляет события в брокер. Если отправка не удалась, её можно повторить.
Таким образом, система не пытается синхронно гарантировать две независимые операции сразу.
Что получает бизнес
Главная выгода — меньше «невидимых» расхождений между системами.
Заказ, платёж или другое действие не должны исчезать из последующих процессов только потому, что в момент изменения произошёл краткий сбой инфраструктуры.
Это снижает количество случаев, когда одна команда видит операцию, а другая вынуждена вручную восстанавливать её последствия.
Для бизнеса это прежде всего про надёжность сквозных процессов и меньше ручных разборов после редких, но дорогих сбоев.
Что получает команда
Команда получает практичный способ связать локальную транзакцию базы с асинхронной публикацией событий без распределённой транзакции.
Но отправка обычно становится как минимум один раз, а значит, потребители должны уметь безопасно обрабатывать повторы.
Нужно также чистить outbox, следить за задержкой публикации и контролировать сообщения, которые не удаётся отправить длительное время.
Что получает клиент
Клиент получает меньше странных состояний: заказ создан, но уведомления нет; платёж прошёл, но бонусы не начислились; документ подписан, но следующий этап процесса не стартовал.
Он не знает про Outbox Pattern, но замечает, когда системы компании согласованно доводят операцию до конца.
Чем мы за это платим
Цена — задержка и дополнительный механизм публикации.
Событие может уйти не мгновенно, а через небольшой промежуток. Появляется таблица outbox, процесс доставки, мониторинг и обработка повторов.
То есть мы меняем простую, но ненадёжную попытку «записать и отправить» на более сложный, зато восстанавливаемый процесс.
Когда Outbox Pattern не нужен
Если система не публикует события после изменения данных или потеря отдельного уведомления допустима, дополнительный механизм может быть лишним.
Он особенно полезен там, где событие запускает важный сквозной бизнес-процесс.
Что стоит спросить перед решением
- Что произойдёт, если данные сохранились, а событие не ушло?
- Допустимы ли повторные события?
- Как быстро событие должно появиться у потребителей?
- Как мы увидим застрявшие записи?
- Кто отвечает за очистку и хранение outbox?
В итоге
Outbox Pattern нужен там, где изменение данных и сообщение об этом должны переживать сбои вместе.
Для бизнеса его ценность в том, что важный процесс не теряется в маленьком техническом зазоре между базой данных и очередью.