Какую проблему мы решаем
В распределённой системе отправитель не всегда знает, обработал ли получатель сообщение. Соединение могло оборваться после обработки, подтверждение могло потеряться, а брокер — доставить событие ещё раз.
Поэтому обещание «доставить хотя бы один раз» полезно для надёжности, но автоматически создаёт риск повторной бизнес-операции.
Как работает Transactional Inbox
Получатель сохраняет идентификатор входящего сообщения вместе с результатом обработки или в той же транзакционной границе. Перед повторной обработкой он проверяет, не видел ли это сообщение раньше.
Если сообщение уже обработано, повтор можно безопасно подтвердить без повторного изменения бизнес-состояния.
Это похоже на idempotency для API, но применяется к асинхронным сообщениям и событиям.
Что получает бизнес
Главный эффект — меньше финансовых и операционных ошибок из-за повторной доставки. Надёжность транспорта перестаёт конфликтовать с корректностью бизнес-операции.
Компания может позволить брокеру и потребителям повторять доставку после сбоев, не превращая восстановление системы в источник новых инцидентов.
Что получает команда
Команда получает явный механизм deduplication и может отделить вопрос доставки от вопроса бизнес-идемпотентности.
Проще строить retry, replay и восстановление после ошибок, потому что повторное сообщение становится ожидаемым сценарием, а не исключением.
Что получает клиент
Клиент получает меньше дублей: повторных списаний, заказов, уведомлений или изменений состояния из-за технического retry.
Система может быть настойчивее в доставке, оставаясь корректной с точки зрения пользователя.
Чем мы за это платим
Нужно хранить идентификаторы сообщений, управлять сроком их жизни и следить, чтобы идентификатор действительно был стабильным и уникальным для бизнес-операции.
Если Inbox хранится отдельно от бизнес-изменения, между ними снова появляется окно несогласованности. Поэтому важна правильная транзакционная граница.
Когда не нужно усложнять
Если операция естественно идемпотентна и повтор не меняет результат, отдельный Inbox может быть лишним.
Он особенно полезен там, где повторное выполнение имеет реальную цену: деньги, лимиты, создание сущностей, внешние вызовы или изменение необратимого состояния.
Что стоит спросить перед решением
- Может ли брокер доставить одно сообщение повторно?
- Что произойдёт при повторном выполнении операции?
- Есть ли у сообщения стабильный уникальный идентификатор?
- Можно ли сохранить факт обработки и бизнес-изменение атомарно?
- Как долго нужно помнить уже обработанные сообщения?
В итоге
Надёжная доставка не означает ровно одно выполнение. В реальных распределённых системах повтор — нормальный сценарий, который нужно проектировать заранее.
Для бизнеса Transactional Inbox ценен тем, что позволяет восстанавливаться после сбоев настойчиво, но без повторного выполнения одной и той же бизнес-операции.