Что такое Saga pattern для распределённых транзакций

Проблема распределённой транзакции

В микросервисах каждый сервис обычно владеет своей БД. Одна бизнес-операция, например оформление заказа, может затронуть Order, Payment, Inventory и Delivery. Обычная ACID-транзакция не может просто охватить независимые сервисы и хранилища без дорогих и хрупких распределённых механизмов.

Как работает Saga

Create order
  |
Reserve inventory
  |
Charge payment
  |
Create shipment
  |
Complete order

If payment fails:
Cancel order
Release inventory reservation

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

Compensating transaction

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

Choreography

При choreography сервисы реагируют на события друг друга. Например, Order публикует OrderCreated, Inventory резервирует товар и публикует InventoryReserved, затем Payment реагирует на это событие.

Orchestration

При orchestration отдельный saga orchestrator явно отправляет команды участникам и принимает решения о следующем шаге или компенсации. Такой подход делает flow более явным, но добавляет центральный компонент координации.

Что необходимо для Saga

идемпотентные handlers и compensations;
retries с backoff и dead-letter queue;
outbox pattern для надёжной публикации событий;
correlation ID и tracing всей saga;
явные состояния pending, completed, failed и compensated;
операционный процесс для зависших и вручную разбираемых saga.

Как ответить на собеседовании

Saga заменяет одну распределённую транзакцию последовательностью локальных транзакций и compensating actions. Она даёт eventual consistency между сервисами. Saga можно координировать через choreography на событиях или через orchestration. Для production нужны идемпотентность, outbox, retries, DLQ, tracing и обработка зависших процессов.

Что такое Saga pattern для распределённых транзакций?