Сага (SAGA) — паттерн надёжности для распределённых транзакций: локальные шаги уже зафиксированы, откат — компенсациями, а не одной транзакцией СУБД.
На каком слое надёжности работает «Сага (SAGA)»
Бизнес-транзакция: распределённый процесс с компенсирующими действиями.
Какой отказ моделирует паттерн «Сага (SAGA)»
локальный шаг уже зафиксирован, а следующий сервис, брокер или человек не завершил свою часть. Система не может откатиться одной СУБД-транзакцией.
Что изолирует «Сага (SAGA)» и где кончается радиус взрыва
радиус «грязного» бизнес-состояния: заказ без оплаты, списание без отгрузки. Отказ одного сервиса не должен оставлять процесс без явного конца (успех, компенсация, ручной разбор).
Когда паттерн «Сага (SAGA)» применять нельзя
если все записи в одной базе и одной транзакции — сага лишняя. Если нужна атомарность без компенсаций — это не сага (и не 2PC «вместо саги»). Нельзя начинать сагу, пока нет компенсаций и идемпотентных шагов.
Что записать в архитектурное решение (ADR) про «Сага (SAGA)»
перечислите шаги, компенсации, кто оркестратор (или события хореографии), идемпотентность, что происходит при потере сообщения.
Оценка качеств «Сага (SAGA)»: масштабируемость, надёжность, сопровождение
Звёзды — ориентир автора сайта, не бенчмарк и не сравнение продуктов.
- масштабируемость: ⭐⭐⭐⭐ (4/5)
- надежность: ⭐⭐⭐⭐ (4/5)
- сопровождение: ⭐⭐ (2/5)
Варианты протокола «Сага (SAGA)» и как выбрать
- Оркестрация: один процесс знает порядок команд и компенсаций. Проще наблюдать, оркестратор — точка отказа и сцепления.
- Хореография: сервисы реагируют на события. Меньше центра, сложнее увидеть «где застряли».
Оба варианта — про смысл процесса, не про повтор HTTP.
Схема взаимодействия: как работает «Сага (SAGA)»
sequenceDiagram
participant Клиент
participant Шаг1
participant Шаг2
Клиент->>Шаг1: выполнить шаг
Шаг1-->>Клиент: зафиксировано
Клиент->>Шаг2: выполнить шаг
Шаг2--xКлиент: отказ
Клиент->>Шаг1: компенсация
Шаг1-->>Клиент: откат смысладля шага в процессе:
выполнить(шаг)
если отказ:
для уже_сделанных в обратном порядке:
компенсация(шаг)
стопТипичные ошибки при внедрении «Сага (SAGA)»
- Нет компенсаций: «сага» превращается в цепочку надежд.
- Компенсация неидемпотентна — повтор события делает хуже, чем отказ.
- Смешать сагу с 2PC шардированной СУБД: другой слой, другая цена блокировок.
С какими паттернами не путать «Сага (SAGA)»
- Ретрай с задержкой (Retry with delay) — чинит короткий сетевой/временный сбой одного вызова, не бизнес-инвариант на нескольких сервисах.
- Резервирование — смена живого контура, процесс при этом может быть одним шагом.
- Sidecar — куда положить прокси, не как согласовать заказ и оплату.
Источники для сверки формулировок про «Сага (SAGA)»
Прямой российской карточки «сага как паттерн» в документации облаков нет; 2PC шардированной СУБД — не замена. Сверка формулировок: Azure Architecture Center: Saga.
Частые вопросы про «Сага (SAGA)»
Когда сага (SAGA) не нужна?
Если все записи в одной базе и одной транзакции. Сага не заменяет 2PC и не чинит короткий сетевой сбой — для этого retry.
Чем оркестрация саги отличается от хореографии?
При оркестрации один процесс знает шаги и компенсации. При хореографии сервисы реагируют на события: меньше центра, сложнее увидеть, где процесс застрял.
Что обязательно до внедрения саги?
Компенсации, идемпотентные шаги и явное завершение процесса: успех, компенсация или ручной разбор.