Оркестрация или хореография саги — когда что

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

Хореография — каждый сервис публикует событие в шину, следующий сервис подписан и реагирует сам. Нет центрального координатора. Подходит, когда шагов мало — два-три, команды между сервисами независимы, а событийная шина (Kafka, RabbitMQ) уже есть в системе.

Проблема хореографии вылезает не сразу. Процесс саги размазан по коду разных сервисов — нет единого места, где написано «вот как выглядит весь флоу». Отладка превращается в чтение логов пяти сервисов подряд. Добавить новый шаг в середину процесса — значит трогать события в нескольких местах одновременно.

Оркестрация — отдельный компонент (оркестратор) явно вызывает каждый шаг и знает всю последовательность. Логика саги видна в одном месте, легче добавлять шаги и тестировать компенсации.

Платите за это вы связанностью: оркестратор знает про все сервисы, которые участвуют в саге, и становится отдельной точкой, которую нужно поддерживать и которая может стать bottleneck.

public class OrderSagaOrchestrator { public void handle(OrderCreatedEvent event) { paymentService.charge(event.getOrderId()); inventoryService.reserve(event.getOrderId()); shippingService.schedule(event.getOrderId()); } }

На собеседовании часто спрашивают: что если шаг оркестрации упал посередине? Ответ — компенсирующие транзакции должны быть идемпотентны и выполняться в обратном порядке от точки сбоя. Если compensate() сам может упасть, нужен retry с бэкоффом и отдельный статус саги в сторонном хранилище, а не только в памяти оркестратора.

Выбор между ними — не вопрос вкуса, а вопрос числа шагов и того, что уже есть в инфраструктуре.

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки