Компенсирующие транзакции: разбор сбоя в заказах

Платёжный сервис списал деньги, склад зарезервировал товар, но сервис доставки не создал отправление. Это типичный частичный сбой распределённой операции: общей транзакции, которая разом откатит три независимые системы, нет. Ниже — разбор условного инцидента в цепочке заказа: цифры производительности не приводятся, потому что без конкретной системы и замеров они были бы выдумкой.

Что произошло: заказ завис между оплатой и доставкой

Представим последовательность: магазин создаёт заказ, платёжный сервис подтверждает списание, склад уменьшает доступный остаток и резервирует товар, затем сервис доставки принимает запрос на создание отправления. Последний шаг завершается тайм-аутом.

Тайм-аут не доказывает, что операция не выполнилась. Запрос мог дойти до службы доставки, а ответ потеряться. Если магазин просто повторит запрос, он рискует создать две отправки. Если сразу вернёт деньги, но отправление всё-таки создалось, в системах появится заказ, который уже отправляют, хотя покупателю сообщили об отмене.

Локальный откат базы магазина здесь не поможет: платёж и резервирование уже зафиксированы в других сервисах. Нужен бизнес-процесс, который знает, какие действия успели завершиться и чем компенсировать каждое из них.

Компенсация — не машина времени. Она создаёт новое действие, которое исправляет бизнес-результат предыдущего.

Как устроена компенсация

В саге* длинная операция разбивается на локальные транзакции. После успешного шага система запускает следующий. Если продолжить нельзя, она выполняет подходящие компенсирующие действия в обратном порядке — но только там, где это ещё допустимо.

Для условного заказа сценарий может выглядеть так:

1. Создать заказ в состоянии «ожидает оплаты».
2. Подтвердить платёж и сохранить идентификатор операции.
3. Зарезервировать товар и сохранить номер резерва.
4. Запросить отправление у службы доставки.
5. Если отправление не создано, выяснить результат запроса, а затем отменить резерв и инициировать возврат платежа, если заказ действительно отменяется.

Порядок компенсаций не всегда буквально обратный. Например, возврат денег может выполняться позже отмены резерва, если политика бизнеса требует сначала подтвердить отмену товара. Это решение нужно зафиксировать в правилах процесса, а не оставлять случайному порядку обработки сообщений.

Сага* — последовательность локальных транзакций в нескольких сервисах, где согласованность достигается продолжением процесса или отдельными компенсирующими операциями, а не общей блокировкой всех баз данных.

Что должно было сработать при тайм-ауте

Сначала выяснить, состоялась ли операция

Повторять создание отправления безопасно только при наличии устойчивого ключа идемпотентности или способа запросить результат по идентификатору операции. Иначе повтор может создать дубль. Если внешний сервис не поддерживает ни идемпотентный запрос, ни проверку состояния, неопределённость придётся обрабатывать отдельной сверкой и ручным разбором.

Не терять факт завершённого шага

Система должна сохранять прогресс саги: заказ, выполненные шаги, идентификаторы внешних операций и состояние компенсации. Если процесс упал после списания, новый воркер должен понимать, что списание уже было, а не отправлять платёжный запрос заново.

Для надёжной передачи событий обычно отдельно решают проблему двойной записи: изменение состояния и публикация сообщения не должны расходиться. Один из распространённых вариантов — записать событие в ту же локальную базу, а затем доставить его брокеру. Выбор механизма зависит от используемого хранилища и брокера; конкретная конфигурация здесь не приводится, потому что тема не привязана к одной версии стека.

Считать компенсацию отдельной операцией

Отмена резерва или возврат платежа тоже могут завершиться тайм-аутом, повториться или временно стать невозможными. Для компенсации нужны собственный идентификатор, повторяемая обработка и состояние вроде «ожидает», «выполняется», «завершена», «требует вмешательства». Ошибка компенсации не должна молча превращать заказ в обычную отмену.

Где подход ломается

Компенсация не всегда полностью возвращает исходное состояние. Уже отправленную посылку нельзя отменить тем же способом, каким снимают складский резерв. Возврат денег может занять время, а внешняя система может отклонить его из-за собственных правил. Поэтому сагу стоит проектировать с учётом бизнес-состояний после каждого шага, а не как набор симметричных вызовов «сделать» и «отменить».

• Повторная доставка сообщения. Обработчик получил событие, выполнил действие, но не подтвердил получение. Сообщение придёт снова. Обработчик должен распознать уже обработанную операцию.
• Запоздалый ответ. После тайм-аута система начала компенсацию, а затем пришло подтверждение исходного действия. Нужны проверки состояния и правила, не позволяющие позднему ответу оживить отменённый заказ.
• Компенсация тоже недоступна. Платёжный сервис может не принимать возвраты или склад — отмену резерва. Процесс должен оставаться видимым для повторной попытки и ручного разбора.
• Два процесса меняют один заказ. Покупатель отменил заказ одновременно с автоматической обработкой доставки. Нужны контроль допустимых переходов и защита от конкурирующих команд.
• Слишком длинная сага. Чем больше шагов и внешних систем, тем больше промежуточных состояний и сценариев отказа. Иногда полезно упростить процесс или вынести необязательное действие за пределы критического пути.

Что измерять вместо одного показателя успешности

Без замеров нельзя честно сказать, насколько компенсации ускорят восстановление или увеличат нагрузку. Для конкретного инцидента сначала соберите временную шкалу и данные по каждому шагу: время запроса, ответ сервиса, повтор, итоговая проверка состояния. Затем сравнивайте периоды при одинаковых объёме заказов, составе сервисов и нагрузке.

В логах и трассировках связывайте шаги общим идентификатором процесса и отдельно записывайте идентификаторы внешних операций. Не кладите в логи платёжные секреты и персональные данные без необходимости. Важно видеть не только ошибку, но и то, было ли действие подтверждено внешней системой.

Как выбирать между сагой, откатом и ручным разбором

Для заказа разумно автоматизировать те компенсации, которые можно безопасно повторять и проверять. Необратимые действия оставляйте за явной границей процесса: если груз уже передан перевозчику, вместо «отменить отправление» может понадобиться отдельный сценарий возврата.

Что делать дальше

Возьмите один реальный заказ, который завис или был обработан дважды, и восстановите цепочку событий по идентификаторам. Отметьте, какие действия уже состоялись, какие можно повторить, а какие требуют сверки. Затем добавьте тесты на тайм-аут после успешного внешнего действия, повторное сообщение, поздний ответ и отказ компенсации. После запуска следите за возрастом незавершённых процессов и долей ручных разборов — они покажут, где система всё ещё оставляет работу людям.

Разбор описывает общий подход для распределённых систем и не привязан к конкретной версии библиотеки, фреймворка или брокера сообщений. Инвалидация кэша и гарантии доставки сообщений в конкретном брокере — отдельные темы.