Что такое Saga pattern?

Saga — это архитектурный паттерн для управления распределёнными транзакциями в микросервисной архитектуре. Когда бизнес-операция затрагивает несколько сервисов с собственными базами данных, классические ACID-транзакции и двухфазный коммит (2PC) становятся плохим выбором: они блокируют ресурсы, плохо масштабируются и требуют жёсткой связности сервисов. Saga решает эту проблему, разбивая одну большую транзакцию на последовательность локальных транзакций, каждая из которых выполняется в рамках одного сервиса.

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

Каждый шаг Saga — это локальная транзакция, которая фиксируется сразу. Если все шаги прошли успешно, бизнес-операция считается завершённой. Если какой-то шаг падает, запускается цепочка компенсирующих транзакций, которые логически отменяют уже выполненные шаги. Важно понимать: компенсация — это не rollback в БД, а отдельная бизнес-операция, например возврат денег или отмена заказа.

Два способа координации

• Choreography — сервисы обмениваются событиями и сами решают, что делать дальше. Просто, но сложно отслеживать общий поток.
• Orchestration — есть центральный оркестратор, который вызывает шаги и управляет компенсациями. Легче контролировать, но появляется единая точка координации.

Пример на псевдокоде

// Saga: оформление заказа
async function placeOrder(order) {
  const steps = [
    { do: () => reserveStock(order), undo: () => releaseStock(order) },
    { do: () => chargePayment(order), undo: () => refundPayment(order) },
    { do: () => shipOrder(order), undo: () => cancelShipment(order) },
  ];

  const done = [];
  for (const step of steps) {
    try {
      await step.do();
      done.push(step);
    } catch (e) {
      // откатываем в обратном порядке
      for (const s of done.reverse()) await s.undo();
      throw e;
    }
  }
}

Где применяется

Saga широко используется в e-commerce (заказ, оплата, доставка), финтехе (переводы между счетами), логистике и любых системах, где одна бизнес-операция затрагивает несколько сервисов. Паттерн даёт eventual consistency вместо строгой согласованности, что приемлемо для большинства бизнес-сценариев.

Итог: Saga стоит применять, когда нужно обеспечить согласованность данных между микросервисами без блокировок и 2PC, а бизнес готов принять eventual consistency и продумать компенсирующие операции для каждого шага.