Как разрешить проблемы с распределенными транзакциями

Что проверяют

Есть ли у вас реальный опыт с операцией, которая меняет данные в нескольких сервисах, и понимаете ли вы, что общей ACID-транзакции там нет. Формат поведенческий: ждут историю, где данные разъехались, и как вы это исправили. Следом спрашивают, почему не 2PC и что будет, если сервис упадёт посередине.

Как отвечать

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

• 2PC/XA: координатор через JTA (Narayana, Atomikos) сначала собирает подтверждения готовности, потом командует коммит. Даёт атомарность, но держит блокировки, зависит от живого координатора и не работает с HTTP-сервисами и Kafka. Поэтому в микросервисах его почти не берут;
• сага: цепочка локальных транзакций с компенсирующими действиями. Хореография через события или оркестратор (свой, Temporal, Camunda). Изоляции нет, промежуточные состояния видны, поэтому вводят статусы вроде PENDING;
• transactional outbox: событие пишется в таблицу outbox в той же локальной транзакции, что и бизнес-данные, а отдельный процесс или Debezium публикует его в Kafka. Так исключается случай «в базе сохранили, событие потеряли»;
• идемпотентный потребитель: доставка гарантируется «как минимум один раз», поэтому обработчик хранит идентификаторы обработанных сообщений или выполняет операцию идемпотентно по ключу;
• сверка: периодическая задача находит зависшие саги и доводит или откатывает их.

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

Где спотыкаются

Отправляют сообщение в Kafka внутри @Transactional сразу после сохранения. Транзакция откатится, а сообщение уже ушло, или наоборот. Именно эту дыру закрывает outbox.

Называют Event Sourcing и CQRS решением проблемы распределённых транзакций. Это способы хранить и читать данные, согласованность между сервисами они не дают.

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