Модуль: Распределённые системы · Уровень: Senior+

TL;DR#

Saga — это способ управлять данными в нескольких сервисах/БД через последовательность локальных транзакций, где каждый шаг публикует событие/команду, запускающую следующий шаг. Если шаг падает, выполняется серия компенсирующих транзакций, откатывающих эффекты предыдущих шагов семантически (а не настоящим rollback). Saga жертвует Isolation из ACID: вы получаете ACD без I. Два стиля координации: оркестрация (центральный координатор дёргает участников командами) и хореография (участники реагируют на события друг друга, без центра). Главные проблемы: отсутствие изоляции (dirty reads, lost updates), компенсации могут падать (нужны ретраи и идемпотентность), часть шагов невозможно компенсировать. Решается это контрмерами (semantic lock, commutative updates, pessimistic view, reread value, by value) и разделением шагов на compensatable / pivot / retriable.

Теория#

Зачем вообще saga#

В монолите с одной БД бизнес-операция «создать заказ» — это одна ACID-транзакция: либо всё закоммитилось, либо всё откатилось. В микросервисной архитектуре с database-per-service данные «заказ», «оплата», «склад», «доставка» лежат в разных БД разных сервисов. Распределённой ACID-транзакции поверх них нет (или она неприемлема — см. ниже про 2PC). Saga — это паттерн поддержания data consistency между сервисами без распределённых транзакций.

Saga = последовательность локальных транзакций T1, T2, …, Tn. Каждая Ti атомарна в рамках своего сервиса. Координация между Ti — через асинхронные сообщения. Если Tk падает — выполняем компенсации Ck-1, Ck-2, …, C1 в обратном порядке.

Happy path:
  T1 ── T2 ── T3 ── T4   (все локальные транзакции прошли)

Failure на T3, откат:
  T1 ── T2 ── T3✗
   │     │
   C1 ◀─ C2            (компенсации в обратном порядке)

Оркестрация vs хореография#

Это два способа ответить на вопрос «кто решает, какой шаг следующий».

Хореография (event-driven, decentralized)#

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

Order Service          Payment Service        Inventory Service
     │                       │                       │
  create order               │                       │
     │── OrderCreated ──────▶│                       │
     │                    charge card                │
     │                       │── PaymentDebited ────▶│
     │                       │                   reserve stock
     │◀───────────────── StockReserved ──────────────│
  approve order

Плюсы:

  • Слабая связанность: сервисы не знают про существование оркестратора, только про события.
  • Нет single point of failure в виде координатора.
  • Просто для коротких saga (2-3 участника).
  • Хорошо ложится на event-driven архитектуру, которая часто уже есть.

Минусы:

  • Логика saga размазана по всем сервисам — нет одного места, где видно весь flow. Тяжело понять и поддерживать.
  • Циклические зависимости между сервисами через события: A слушает B, B слушает A.
  • Риск, что сервис подписан на события, которые его не касаются («event coupling»).
  • Тяжело отлаживать и тестировать: чтобы понять процесс, надо собрать его из подписок в N репозиториях.
  • Сложно реализовать сложные условные ветвления.

Оркестрация (central orchestrator, command-driven)#

Есть отдельный объект/сервис — Saga Orchestrator (часто реализуется как state machine / persistent state machine, напр. через outbox + таблицу состояний). Он шлёт команды участникам и реагирует на их ответы, продвигая стейт-машину.

            ┌──────────────────────────┐
            │   Order Saga Orchestrator│
            │   (state machine)        │
            └──────────────────────────┘
              │ cmd        ▲ reply
              ▼            │
        ┌──────────┐  ┌──────────┐  ┌──────────┐
        │ Payment  │  │Inventory │  │ Delivery │
        └──────────┘  └──────────┘  └──────────┘

Flow: Orchestrator → ChargeCard → (ok) → ReserveStock → (ok) → ScheduleDelivery → done
      на любом fail: Orchestrator запускает компенсации в обратном порядке

Плюсы:

  • Логика централизована — весь flow в одном месте, легко читать, тестировать, версионировать.
  • Участники не знают друг про друга, только выполняют команды → меньше связанности между участниками.
  • Легко реализовать сложную логику: условия, параллельные ветки, таймауты, ретраи.
  • Проще observability: состояние saga персистится, видно где «застряла».
  • Нет цикл. зависимостей.

Минусы:

  • Риск, что бизнес-логика «утечёт» в оркестратор, а участники станут анемичными (антипаттерн «god orchestrator»).
  • Оркестратор — дополнительный компонент, который надо разрабатывать, деплоить, делать отказоустойчивым (его state machine должна переживать рестарты → persistent saga state).
  • Потенциальный (но управляемый) single point of coordination.

Что выбирать#

КритерийХореографияОркестрация
Кол-во участников2-4много / сложный flow
Сложность логикипростая, линейнаяусловия, ветвления
Связанностьнизкая между сервисами и центром, но высокая event-couplingнизкая между участниками
Наблюдаемость flowплохая (размазана)хорошая (централизована)
Точка отказанет координатораоркестратор (нужна устойчивость)

Практическое правило: для нетривиальных бизнес-процессов на senior+ почти всегда выбирают оркестрацию ради maintainability и observability, держа оркестратор «тонким».

Компенсирующие транзакции — это semantic rollback, не настоящий rollback#

Ключевая идея, которую часто проваливают на собеседовании: компенсация не откатывает транзакцию в смысле БД (данные уже закоммичены и видны другим). Компенсация — это новая транзакция, которая семантически нейтрализует эффект предыдущей.

  • «Зарезервировали 10 единиц на складе» → компенсация: «снять резерв 10 единиц» (не ROLLBACK, а отдельный апдейт).
  • «Списали $100 с карты» → компенсация: «вернуть $100» (refund — отдельная финансовая операция, может занять дни).
  • «Отправили email с подтверждением» → компенсировать невозможно (письмо уже ушло). Максимум — отправить второе письмо «извините, отмена». Это non-compensatable шаг.

Из-за этого важна классификация шагов:

Compensatable / Pivot / Retriable#

Саги обычно структурируют так, чтобы существовала pivot transaction — точка невозврата:

  • Compensatable transactions — шаги в начале saga, которые можно компенсировать. Идут до pivot.
  • Pivot transaction — «go / no-go» точка. После неё saga обязана дойти до конца. Сам pivot — это либо последняя компенсируемая транзакция, либо первая ретраибельная. Пример: списание денег как pivot — после него мы коммитимся к выполнению заказа.
  • Retriable transactions — шаги после pivot, которые гарантированно завершатся (повторяются до успеха), и которые не нужно компенсировать. Их проектируют так, чтобы они не могли провалиться по бизнес-причине (только по техническим, → ретрай).
 [ T1 ]   [ T2 ]   ║  [ Pivot ]  ║   [ T3 ]   [ T4 ]
 compensatable      ║   точка     ║    retriable
                    ║  невозврата ║   (только ретраи, без компенсации)
 ◀── можно откатить ║             ║  ── только вперёд, до успеха ──▶

Идея: до pivot можно отменить всё; после pivot отмена дороже/невозможна, поэтому всё спроектировано так, чтобы дожать до конца ретраями.

Когда saga вместо 2PC (two-phase commit)#

2PC (XA-транзакции) даёт настоящую распределённую ACID-транзакцию с изоляцией, но:

  • Блокирующий протокол: координатор упал между prepare и commit → участники держат локи на ресурсах неопределённо долго (blocking problem). Это убивает доступность.
  • Плохо масштабируется, держит локи на время всего round-trip → низкая throughput.
  • Требует поддержки XA от всех ресурсов; современные брокеры (Kafka), многие NoSQL БД, внешние HTTP-API его не поддерживают.
  • Противоречит автономности сервисов и database-per-service.
  • По CAP жертвует доступностью.

Saga вместо 2PC выбирают, когда:

  • Участники — разные технологии / внешние API без XA.
  • Нужна высокая доступность и отсутствие распределённых локов.
  • Бизнес-процесс длительный (long-running, секунды–дни: ожидание оплаты, доставки).
  • Допустима eventual consistency и отсутствие изоляции (с применением контрмер).

Saga не подходит (или нужна особая осторожность), когда нужна строгая изоляция в реальном времени и бизнес не терпит промежуточных несогласованных состояний на коротком окне без контрмер.

Сложности saga (ACD без I)#

Saga даёт Atomicity (через компенсации), Consistency (eventual), Durability (локальные транзакции durable), но НЕ даёт Isolation. Отсутствие I порождает аномалии — те же, что и при низких уровнях изоляции в СУБД:

  • Lost updates — saga A перезаписывает изменения, сделанные saga B, не прочитав их.
  • Dirty reads — saga B читает данные, записанные saga A до того, как A откатилась компенсацией.
  • Fuzzy / non-repeatable reads — разные шаги одной saga видят разные значения, потому что между ними другая saga изменила данные.

Дополнительно:

  • Компенсация может упасть. Сеть, недоступность сервиса, баг. Компенсация — это сетевой вызов, который тоже ненадёжен. → Компенсации должны ретраиться до успеха (at-least-once delivery), часто с exponential backoff и DLQ + алертом + ручным вмешательством как последний рубеж.
  • Идемпотентность обязательна и для шагов, и для компенсаций. Из-за at-least-once доставки сообщений один и тот же шаг/компенсация может прийти дважды. Повторный «refund $100» не должен вернуть $200. Реализуют через дедупликацию по message id / idempotency key, проверку текущего состояния перед применением.
  • Commutativity компенсаций: иногда компенсация приходит до того, как пришла исходная команда (out-of-order). Шаги должны корректно обрабатывать и это.

Countermeasures (контрмеры против отсутствия изоляции)#

Из работы Chris Richardson / Caitie McCaffrey. Цель — снизить или устранить аномалии без настоящих локов.

  • Semantic lock — приложение помечает запись «флагом» (например *_PENDING: ORDER_PENDING, payment = PENDING), пока saga не завершилась. Compensatable-транзакция ставит флаг, retriable/финальная — снимает. Другие saga, видя флаг, либо ждут, либо отказываются, либо обрабатывают как блокировку прикладного уровня. Самая распространённая контрмера. Требует логики обработки «занятых» записей (фактически прикладной 2PL).
  • Commutative updates — проектировать операции коммутативными, чтобы порядок применения не влиял на результат. Классика: +100 и -100 коммутативны. Тогда dirty read/lost update менее опасны: компенсация (-100) корректно отменяет (+100) независимо от порядка.
  • Pessimistic view — переупорядочить шаги saga так, чтобы минимизировать бизнес-риск от dirty read. Пример: при отмене заказа сначала уменьшить доступный кредит клиента (или не увеличивать лимит), и только потом делать рискованные шаги — чтобы клиент в промежутке не «увёл» средства.
  • Reread value — оптимистическая блокировка: перед апдейтом перечитать запись и проверить, что она не изменилась с момента предыдущего чтения (version / etag). Если изменилась — abort и пересчёт. Предотвращает lost updates.
  • By value — выбирать стратегию управления конкурентностью динамически по бизнес-риску запроса. Низкорисковые операции (мелкая сумма) идут через saga с контрмерами; высокорисковые (крупный платёж) — через распределённую транзакцию / 2PC или ручную проверку. Гибрид.
// Пример semantic lock + идемпотентность шага компенсации
func (s *PaymentService) RefundPayment(ctx context.Context, cmd RefundCmd) error {
    return s.tx(ctx, func(tx *sql.Tx) error {
        // идемпотентность: дедуп по saga/idempotency key
        var alreadyDone bool
        err := tx.QueryRowContext(ctx,
            `SELECT EXISTS(SELECT 1 FROM processed_commands WHERE id=$1)`,
            cmd.IdempotencyKey).Scan(&alreadyDone)
        if err != nil {
            return err
        }
        if alreadyDone {
            return nil // уже компенсировали — no-op, но шлём ack
        }

        var status string
        // semantic lock: работаем только если платёж в нужном состоянии
        err = tx.QueryRowContext(ctx,
            `SELECT status FROM payments WHERE id=$1 FOR UPDATE`,
            cmd.PaymentID).Scan(&status)
        if err != nil {
            return err
        }
        if status != "DEBITED" {
            // нечего возвращать (out-of-order / уже refunded) — коммутативно безопасно
            return s.markProcessed(ctx, tx, cmd.IdempotencyKey)
        }

        if _, err := tx.ExecContext(ctx,
            `UPDATE payments SET status='REFUNDED', balance=balance+$2 WHERE id=$1`,
            cmd.PaymentID, cmd.Amount); err != nil {
            return err
        }
        return s.markProcessed(ctx, tx, cmd.IdempotencyKey)
    })
}

Полная ASCII-диаграмма flow с компенсацией#

 CreateOrder Saga (оркестрация)

 Orchestrator state machine:

   START
     │ cmd: CreateOrder(PENDING)            [compensatable, semantic lock = PENDING]
     ▼
   ORDER_CREATED ──────fail──▶ reject locally, END(FAILED)
     │ cmd: ReserveStock                    [compensatable]
     ▼
   STOCK_RESERVED ─────fail──▶ C: CancelOrder ─▶ END(FAILED)
     │ cmd: ChargePayment   ═══ PIVOT ═══   [после успеха — только вперёд]
     ▼
   PAYMENT_DONE ───fail──▶ C: ReleaseStock ─▶ C: CancelOrder ─▶ END(FAILED)
     │ cmd: ScheduleDelivery                [retriable: ретраим до успеха]
     ▼
   DELIVERY_SCHEDULED
     │ cmd: ApproveOrder (status=APPROVED)  [retriable: снимаем semantic lock]
     ▼
   END(SUCCESS)

 Каждая стрелка вниз = команда + ожидание reply.
 Любой reply=fail ДО pivot → запуск цепочки компенсаций C в обратном порядке.
 Любой fail ПОСЛЕ pivot → НЕ компенсируем, а ретраим шаг до успеха.

Подводные камни / gotchas#

  • Компенсация — это не ROLLBACK. Данные уже видны другим. Думать в терминах «обратной бизнес-операции», а не отката БД.
  • Забыли про идемпотентность. At-least-once доставка + ретраи → двойное списание/начисление. Нужен idempotency key и дедупликация на каждом шаге И каждой компенсации.
  • Компенсация падает и нет ретрая/DLQ. Saga зависает в неконсистентном состоянии. Нужны: ретраи с backoff, DLQ, алерты, ручной runbook. Компенсации проектировать максимально надёжными (locally retriable).
  • Non-compensatable шаги выполнены слишком рано. Отправка email / вызов внешнего необратимого API нужно делать после pivot (в retriable-зоне) или вообще в самом конце.
  • Out-of-order сообщения. Компенсация может прийти раньше команды. Шаги должны быть коммутативны или проверять состояние.
  • Игнор отсутствия изоляции. Dirty read привёл к тому, что другой процесс принял решение по «грязным» данным, которые потом откатились. Применять semantic lock / pessimistic view.
  • God orchestrator. Вся бизнес-логика уехала в оркестратор, сервисы стали CRUD-обёртками. Оркестратор должен координировать, а не содержать всю доменную логику.
  • Saga state не персистится. Оркестратор перезапустился — забыл, где была saga. State machine обязана быть durable (таблица + outbox).
  • Двойная публикация (dual write). Закоммитили в БД и упали до публикации события (или наоборот). Использовать transactional outbox + CDC/poller, чтобы запись состояния и публикация события были атомарны.
  • Тайм-ауты не обрабатываются. Участник не ответил вообще. Нужны таймауты в стейт-машине, которые тоже запускают компенсацию.

Вопросы на собеседовании#

В: Чем компенсирующая транзакция отличается от rollback в БД? О: Rollback откатывает незакоммиченную транзакцию, и её эффекты никогда не были видны другим. Компенсация — это новая, отдельная транзакция, которая семантически нейтрализует уже закоммиченный и видимый эффект (резерв снять, деньги вернуть). Поэтому она не всегда возможна (email не вернуть), может сама упасть и требует идемпотентности и ретраев.

В: Saga vs 2PC — когда что? О: 2PC даёт настоящую ACID-изоляцию, но это блокирующий протокол (координатор упал → локи висят), плохо масштабируется и требует XA-поддержки от всех участников. Saga выбирают, когда участники гетерогенны/внешние API без XA, нужна высокая доступность без распределённых локов, процесс длительный, и допустима eventual consistency с контрмерами вместо изоляции.

В: Оркестрация или хореография для процесса из 6 сервисов с условными ветвлениями? О: Оркестрация. Хореография при таком масштабе размазывает логику по всем сервисам, плодит event-coupling и циклические зависимости, делает невозможным понимание и отладку flow. Оркестратор централизует логику, даёт наблюдаемость и легко выражает ветвления. Держать его тонким, чтобы не превратить в god-объект.

В: Saga даёт ACID? О: Даёт ACD, но не Isolation. Atomicity — через компенсации, Consistency — eventual, Durability — за счёт локальных durable-транзакций. Отсутствие изоляции порождает аномалии: dirty reads, lost updates, non-repeatable reads. Их закрывают контрмерами (semantic lock, commutative updates, pessimistic view, reread value, by value).

В: Что такое pivot transaction? О: Точка невозврата в saga. Шаги до pivot — compensatable (можно откатить). Pivot — go/no-go решение. Шаги после pivot — retriable: они гарантированно завершаются (ретраятся до успеха) и не компенсируются. Это структурирует saga так, чтобы необратимые/дорогие шаги были после точки, начиная с которой мы коммитимся довести процесс до конца.

В: Почему идемпотентность обязательна? О: Доставка сообщений at-least-once, плюс ретраи компенсаций → один шаг или компенсация может прийти несколько раз. Без идемпотентности это двойное списание, двойной refund, двойной резерв. Реализуют через idempotency key + таблицу обработанных команд / проверку текущего состояния перед применением.

В: Что делать, если компенсация падает? О: Компенсация — сетевой вызов и тоже ненадёжна. Её нужно ретраить (at-least-once, exponential backoff), и она должна быть идемпотентной. На исчерпание ретраев — DLQ + алерт + runbook для ручного разбора. Сами компенсации проектируют максимально безотказными (минимум зависимостей, locally retriable), и ставят необратимые шаги после pivot, чтобы их не приходилось компенсировать.

В: Что такое semantic lock и зачем он? О: Прикладной флаг на записи (PENDING), который ставит compensatable-транзакция и снимает финальная. Пока флаг стоит, другие saga либо ждут, либо отвергаются, либо обрабатывают как занято. Это контрмера против отсутствия изоляции — фактически прикладной двухфазный лок, предотвращающий dirty read/lost update на время выполнения saga.

В: Как избежать dual write проблемы (БД + брокер)? О: Transactional outbox: в той же локальной транзакции, что и изменение состояния, пишем событие в таблицу outbox. Отдельный poller/CDC читает outbox и публикует в брокер с at-least-once. Так запись и «намерение опубликовать» атомарны; потребители дедуплицируют по message id.

На что копают на senior+#

  • Чёткое понимание, что компенсация — semantic rollback, и какие шаги в принципе не компенсируемы, как это влияет на порядок шагов и на pivot.
  • Классификация шагов на compensatable / pivot / retriable и умение объяснить, почему это снижает сложность обработки сбоев.
  • Глубина по отсутствию изоляции: назвать конкретные аномалии (dirty read, lost update, non-repeatable read) и сопоставить им конкретные контрмеры.
  • Идемпотентность и at-least-once на уровне реализации: idempotency key, дедупликация, обработка out-of-order и повторных компенсаций.
  • Transactional outbox / inbox как решение dual-write, понимание CDC.
  • Durable saga state machine, обработка таймаутов и зависших saga, observability и runbook на упавшие компенсации.
  • Осознанный выбор оркестрация vs хореография по конкретному кейсу с аргументами, а не «по вкусу».
  • Понимание границ применимости: где saga неприемлема и нужна синхронная согласованность/2PC или by-value-гибрид (крупные деньги, критичный инвентарь).