Saga — это паттерн управления распределенными транзакциями в микросервисной архитектуре, позволяющий обеспечивать согласованность данных без двухфазных коммитов. Вместо глобальной транзакции каждый сервис выполняет свою локальную транзакцию и генерирует события о её завершении.
Существуют два варианта реализации: оркестрация, когда есть центральный координатор; и хореография, когда сервисы реагируют на события друг друга. Выбор подхода зависит от сложности бизнес-процесса и количества участников.
Saga повышает масштабируемость, снижает связанность сервисов и делает архитектуру устойчивой к ошибкам. При этом возрастает сложность проектирования компенсационных действий и обработки ошибок.
Saga — это фундаментальный паттерн построения распределенных систем, особенно микросервисных. Он решает ключевую проблему: как обеспечить согласованность бизнес-процессов, состоящих из множества локальных транзакций в разных сервисах, не нарушая принципа автономности Bounded Context. В классической монолитной архитектуре транзакции выполнялись в одной базе, и согласованность обеспечивалась автоматически. В микросервисах — база данных у каждого своя, а глобальные транзакции технически невозможны. Saga решает эту проблему, позволяя строить надежные и предсказуемые процессы.
Saga состоит из последовательности локальных транзакций, каждая из которых выполняется полностью в пределах одного сервиса. После успешного выполнения сервис фиксирует изменения и публикует событие. Остальные участники реагируют на это событие, выполняют собственные транзакции и генерируют свои события. Если на каком-то шаге возникает ошибка — запускаются компенсационные транзакции, которые отменяют или компенсируют эффекты предыдущих шагов. Именно компенсации являются сердцем Saga: архитектор должен продумать, как отменить операцию с учетом реальности бизнеса, где полная отмена часто невозможна.
Существует два подхода к реализации Saga: оркестрация и хореография. В оркестрации есть один руководитель процесса — Saga Orchestrator — который вызывает операции сервисов и следит за выполнением. Этот подход повышает управляемость, но создаёт центральную точку координации. В хореографии сервисы реагируют только на события и сами решают, когда выполнять свои действия, что повышает масштабируемость, но усложняет трассировку и понимание общего процесса. Архитектор выбирает подход, исходя из сложности бизнес-сценария: если процесс линейный и хорошо формализован — оркестрация, если динамический, с большим количеством ветвлений — хореография.
Saga тесно интегрируется с другими паттернами: Event-Driven Architecture, Domain Events, Event Sourcing, CQRS, Outbox Pattern и Message Relay. Для надежной работы требуются механизмы идемпотентности, retry, dead letter queues и распределенная трассировка. На практике Saga применяется в банковских системах, e-commerce, логистике, биллинге, страховании — везде, где есть длинные цепочки действий, распределенных между различными сервисами.
На рынке труда Saga — один из наиболее востребованных архитектурных навыков. Архитекторы, умеющие проектировать распределенные транзакции, компенсации, события и интеграцию микросервисов, требуются в банковском секторе, финтехе, телекоме, маркетплейсах и AI-платформах. Умение объяснить, когда Saga применять нельзя, ещё ценнее: паттерн не подходит для операций, требующих строгой изолированной транзакционности или низкой задержки, и архитектор должен уметь сочетать Saga с другими паттернами согласованности.