Строгую атомарность дают поддерживаемые распределённые транзакции, например 2PC, либо перенос инварианта в одну транзакционную границу. Saga обеспечивает компенсации, но не равна общему ACID rollback.
Есть несколько сервисов (2-3), и есть сквозной бизнес-сценарий, проходящий через все сервисы. Если операция на каком-то из сервисов посередине или под конец сломалась, система оказывается в неконсистентном состоянии. Какими способами можно добиться межсервисной транзакционности (либо весь сценарий применился, либо не применился вообще), если у каждого сервиса своя база данных?
Строгую атомарность дают поддерживаемые распределённые транзакции, например 2PC, либо перенос инварианта в одну транзакционную границу. Saga обеспечивает компенсации, но не равна общему ACID rollback.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Строгую атомарность дают поддерживаемые распределённые транзакции, например 2PC, либо перенос инварианта в одну транзакционную границу. Saga обеспечивает компенсации, но не равна общему ACID rollback.
2PC требует поддержки участников и надёжного координатора, удерживает ресурсы и усложняет восстановление. Saga разбивает процесс на локальные транзакции с повторяемыми шагами и компенсациями; промежуточные состояния видимы, а компенсация тоже может ошибиться. Поэтому нужны статусы, идемпотентность и reconciliation. Сначала уточните, действительно ли требуется отсутствие любых промежуточных эффектов: внешнее письмо или уже выполненную доставку невозможно буквально отменить транзакцией БД.
Источник: docs.oracle.com.