Этот вопрос проверяет понимание того, как поддерживать согласованность данных без глобальных транзакций.
В распределённых системах обычно нельзя использовать одну ACID-транзакцию на все сервисы. Вместо этого применяют Saga-подход, где каждый шаг имеет компенсирующее действие. Если один шаг падает, запускаются компенсации для уже выполненных шагов. Компенсации — это не “rollback”, а бизнес-обратные операции. Часто они реализуются через события и оркестрацию.
Компенсационное действие — это операция, которая логически отменяет эффект ранее успешно выполненного шага в распределённом процессе.
Нет общей БД и общего transaction manager.
Шаги выполняются в разных сервисах и в разное время.
Данные могли уже использоваться другими процессами.
Saga — это последовательность локальных транзакций, где:
каждый шаг фиксирует изменения локально;
для каждого шага определено compensation action.
Оркестрация
Центральный координатор знает порядок шагов.
Он же решает, какие компенсации запускать.
Проще контролировать, сложнее масштабировать.
Хореография
Сервисы реагируют на события друг друга.
Нет центрального управляющего сервиса.
Меньше связанность, сложнее отлаживать поток.
# Псевдокод оркестратора
try:
reserve_stock()
withdraw_money()
create_order()
except Exception:
compensate_create_order()
compensate_withdraw_money()
compensate_reserve_stock()
Компенсации должны быть идемпотентными.
Компенсация может не вернуть систему в исходное состояние на 100%.
Нужны ретраи, дед-леттеры и ручные процедуры для “зависших” саг.
Компенсации — это бизнес-rollback, а не технический. Они являются основой Saga-подхода и позволяют жить без распределённых транзакций.
