Знаете ли готовые фреймворки для реализации паттерна саги

Что проверяют

Знаете ли вы саги по инструментам, а не только по диаграмме из книги, и понимаете ли разницу между оркестрацией и хореографией. Следом обычно спрашивают, как вы писали компенсации и что делать, если упала сама компенсация.

Как отвечать

Одна фраза про паттерн: сага это цепочка локальных транзакций в разных сервисах, у каждого шага есть компенсирующее действие, а согласованность достигается в итоге, без распределённого 2PC. Дальше инструменты для Java:

• Temporal: оркестрация как код. Сага пишется обычным методом workflow, состояние хранит сервер Temporal, ретраи и таймауты встроены. В Java SDK есть класс Saga с addCompensation() и compensate();
• Camunda: оркестрация через BPMN-процесс, компенсации задаются компенсационными событиями. Удобно, когда процесс должны видеть аналитики и бизнес;
• Axon Framework: саги поверх событий, аннотации @Saga, @StartSaga, @SagaEventHandler, @EndSaga. Естественно ложится на CQRS и Event Sourcing, обычно в паре с Axon Server;
• Eventuate Tram Sagas: оркестрируемые саги на Spring Boot с транзакционным outbox, из экосистемы Криса Ричардсона, автора «Microservices Patterns»;
• Apache Camel: EIP Saga с координатором LRA, например Narayana. Стандарт MicroProfile LRA поддерживает и Quarkus.

Для хореографии фреймворк не обязателен: сервисы обмениваются событиями через Kafka, а надёжность дают outbox и идемпотентные обработчики.

Закончите выбором: что взяли бы и почему. Temporal удобен для новой оркестрации, но это отдельный кластер, который надо эксплуатировать.

Где спотыкаются

Называют инструменты, которые не про саги: Spring Cloud Data Flow (оркестрация потоков данных) или NServiceBus, который существует только для .NET.

Не продумывают идемпотентность шагов и компенсаций. При повторной доставке сообщения списание пройдёт дважды.

Считают компенсацию откатом. Отправленное письмо не отзовёшь, поэтому компенсация это новое действие с бизнес-смыслом, например возврат денег.