Саги, компенсации и паттерн outbox

Почему не одна транзакция: 2PC — хрупкий SPOF

Операция «разместить заказ» затрагивает три сервиса — order, inventory, payment — и каждый владеет своей базой. Инстинкт из монолитных времён — обернуть все три записи в одну транзакцию, чтобы они коммитились или откатывались вместе. Нельзя. ACID-транзакция живёт внутри одной базы; она не может охватить три независимые базы, принадлежащие трём независимым сервисам.

Классический ответ на «атомарность поверх нескольких баз» — это двухфазный коммит (2PC / XA): координатор транзакции просит каждого участника prepare, и когда все проголосовали «да», велит всем commit. Атомарность он даёт — и почти каждый современный микросервисный стек отказывается его использовать по трём причинам, которые усугубляют друг друга под нагрузкой:

• Координатор — единая точка отказа. Если он умирает после того, как участники проголосовали prepare, но до того, как он разослал commit, каждый участник застревает, удерживая блокировки, в ожидании решения, которое может не прийти никогда.
• Блокировки удерживаются через сеть. Между prepare и commit каждая база держит свои блокировки на весь круг до каждого другого участника. При партишене или замедлении эти блокировки просто висят, и пропускная способность рушится.
• Доступность падает при партишене. 2PC — это CP-протокол в жёстком смысле: если любой участник или координатор недоступен, вся транзакция блокируется. Один медленный сервис стопорит всех.

Поэтому модель консистентности меняется. Вместо одной транзакции, атомарной прямо сейчас, ты принимаешь eventual consistency: шаги происходят по одному, каждый атомарен сам по себе, и система сходится к корректному состоянию вскоре после — не мгновенно. Паттерн, который это делает, — сага.

Сага: локальные транзакции плюс компенсации

Сага — это последовательность локальных транзакций, каждая из которых выполняется внутри собственной базы одного сервиса, связанных событиями или командами. Резервирование инвентаря — одна локальная транзакция в базе inventory. Списание платежа — другая локальная транзакция в базе payment. Каждая коммитится сама по себе. Сага — это цепочка.

Сложная часть — отказ. Если шаг 3 (списать платёж) падает, ты не можешь откатить шаги 1 и 2 — они уже закоммитились. Закоммиченная локальная транзакция исчезла; никакого ROLLBACK выпустить нельзя. Вместо этого сага запускает компенсирующие транзакции: новую локальную транзакцию, которая семантически отменяет предыдущую. Ты не «отсписываешь» платёж; ты делаешь возврат. Ты не «отрезервируешь» инвентарь; ты снимаешь резерв.

// A saga step is a local txn + a named compensation. The orchestrator runs the
// forward action; if a LATER step fails, it runs each completed step's compensate().
interface SagaStep {
  action: () => Promise<void>;      // local transaction in ONE service
  compensate: () => Promise<void>;  // semantic undo, runs AFTER commit, may itself fail
}

const placeOrderSaga: SagaStep[] = [
  { action: () => inventory.reserve(orderId, items),
    compensate: () => inventory.release(orderId) },        // not a rollback — a release
  { action: () => payment.charge(orderId, total),
    compensate: () => payment.refund(orderId) },           // not a rollback — a refund
];

Есть два способа координировать цепочку, и выбор между ними — сеньорское решение:

• Хореография — без центрального координатора. Каждый сервис слушает события и эмитит следующее. Order-сервис эмитит order.created; inventory реагирует, резервирует, эмитит inventory.reserved; payment реагирует уже на него. Децентрализованно и просто для коротких потоков — но общий поток не живёт нигде в коде. Чтобы ответить «что происходит при размещении заказа», ты читаешь обработчики событий пяти сервисов и собираешь поток у себя в голове. Он гниёт по мере роста.
• Оркестрация — центральный оркестратор саги владеет потоком. Он шлёт явные команды (reserveInventory, потом chargePayment), отслеживает состояние саги в своей таблице и решает, когда запускать компенсации. Это ещё один компонент, который надо построить и эксплуатировать, но поток в одном месте: явный, наблюдаемый, тестируемый, перезапускаемый.

Сеньорское эмпирическое правило: хореография для коротких потоков на 2–3 шага; оркестрация, когда поток длинный, ветвистый или требует наблюдаемости — всё, что придётся дебажить в три ночи, хочет машину состояний, которую можно запросить.

Вместе эти два стиля покрывают весь спектр координации: хореография даёт ноль новых компонентов и никакого централизованного состояния, а оркестрация — одно место, чтобы ответить «где сейчас находится эта сага?». Без этого единственного места провальный платёж в пятисервисной хореографии требует читать пять журналов событий, чтобы восстановить произошедшее.

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

Инцидент из Hook — это проблема двойной записи (dual-write), и она настоящая причина существования этого урока. Сервису почти всегда приходится делать две записи как часть одного логического шага: обновить свою базу (строку заказа) и опубликовать событие, чтобы другие сервисы о нём узнали (order.created). Это две системы — БД и брокер — без общей транзакции. В каком бы порядке ты их ни делал, краш в зазоре тебя ломает:

• Сначала БД, потом публикация, краш в промежутке → заказ существует, но событие не отправлено. Сервисы вниз по потоку никогда не узнают, что заказ существует. Инвентарь не резервирует; клиент ждёт вечно. Это Hook.
• Сначала публикация, потом запись в БД, БД падает → ты опубликовал order.created для заказа, которого не существует. Теперь сервисы вниз по потоку действуют на ложь, и фантомный заказ расходится по системе.

Транзакционный outbox чинит это, убирая вторую систему из критической записи. В той же локальной транзакции базы, что пишет бизнес-строку, ты также делаешь INSERT события в таблицу outbox. Обе строки коммитятся вместе или ни одна — это одна транзакция в одной базе, так что зазора нет:

// Оба INSERT в ОДНОЙ локальной транзакции: бизнес-строка и строка события коммитятся атомарно.
await this.dataSource.transaction(async (manager) => {
  const order = await manager.getRepository(Order).save(newOrder);
  await manager.getRepository(OutboxEvent).insert({
    aggregateId: order.id,
    type: 'order.created',
    payload: JSON.stringify({ orderId: order.id, items: order.items }),
    // status defaults to 'pending'; a relay flips it to 'sent' after publishing
  });
}); // <- if the pod dies here, NEITHER row committed. No half state. No lost event.

Отдельный message relay затем доносит строки outbox до брокера. Две распространённые реализации:

• Polling publisher — фоновый воркер делает SELECT строк pending, публикует каждую в брокер и помечает её sent (или удаляет). Просто, без лишней инфраструктуры; цена — задержка опроса и нагрузка.
• Change Data Capture (CDC) — инструмент вроде Debezium читает журнал упреждающей записи (WAL) базы, видит INSERT в outbox и публикует его. Почти реальное время и без опроса, но это серьёзный кусок инфраструктуры в эксплуатации.

В любом случае relay гарантирует публикацию at-least-once: он продолжает попытки, пока брокер не подтвердит, так что отказ публикации или краш relay означает ретрай, а не потерянное событие. At-least-once означает, что консьюмер может увидеть одно и то же событие дважды — и ровно здесь зарабатывают идемпотентные консьюмеры из предыдущего урока (L03): дедупликация по id события вниз по потоку, и доставка at-least-once плюс идемпотентная обработка дают тебе effectively-once. Outbox не заменяет семантику доставки; он питает её надёжным источником.

// Relay: публикация at-least-once. Держит событие, пока брокер не подтвердит.
async function relayTick(manager: EntityManager, client: ClientProxy) {
  const pending = await manager.getRepository(OutboxEvent)
    .find({ where: { status: 'pending' }, take: 100, order: { id: 'ASC' } });
  for (const evt of pending) {
    await firstValueFrom(client.emit(evt.type, JSON.parse(evt.payload))); // may retry
    await manager.getRepository(OutboxEvent).update(evt.id, { status: 'sent' });
  }
}