SAGA

Зачем

• Чтобы отказаться от two phase commit в распределенной среде - плохо масштабируемый алгоритм.
• Распределенная транзакция - зло, необходимо избегать разделяя правильно на ограниченные контексты DDD
• Паттерн обеспечения согласованности(консистентности) данных при распределенных (бизнес) транзакциях, решает проблемы производительности Long Lived Trasactioin (LLT).
• Решения по обеспечению надёжности (констистентности) транзакций, стали востребованы в микросервисной архитектуре.
• Сага состоит из действий (actions) направленных на обеспечение консистентности транзакций, включая компенсации, и является при этом неатомарной единицей (unit) консистентности
• При реализации саг особое внимание нужно уделять изоляции

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

• Backward recovery
• Forward recovery
• Компенсирующие действия
• Реализация при помощи Оркестровки или Хореографии
  • Оркестратор - ИС которая управляет изменениями в Х ИС
  • Хореография - Каждая ИС сама подписывается на события в Шине Сообщений и реагирует на изменния
  • Реализации возможна на BPMN workflow engine (Camunda например)

TODO

• https://t.me/microservices_arch/307
• https://t.me/ru_arc/112

Состоит из:

• машины состояний state machine
• наблюдателя (Observer) для логирования

Паттерны

Технологии

• Debezium + Kafka
• serverless saga pattern by using AWS Step Functions
• MassTransit example