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

Как организовать взаимодействие между этими независимыми акторами, чтобы гарантировать целостность бизнес-операции? В архитектуре EDM используются два фундаментальных паттерна — хореография и оркестровка. А когда речь заходит о согласованности данных, на сцену выходит паттерн Saga.

Это восьмая глава цикла. Она опирается на главу III (контракты событий), главу IV (Transactional Outbox) и главу VII (state stores). Здесь мы разберём, как эти механизмы складываются в сквозные бизнес-процессы.

IХореография: танцплощадка событий

В хореографической архитектуре нет центрального управляющего органа. Каждый микросервис самостоятельно «слушает» потоки событий и реагирует на них, публикуя свои собственные события в ответ. Это напоминает танцоров на вечеринке: каждый знает свои шаги и движется в ритм общей музыки, но дирижёра нет.

Сервис А завершает свою часть работы и публикует OrderCreated. Сервис Б, отвечающий за резервирование товаров, подписан на этот поток. Получив событие, он резервирует товар и публикует InventoryReserved. Сервис В (списание средств) подхватывает событие — и так далее.

Сервис А не знает о существовании сервисов Б и В. Он просто бросает факт в «эфир». Новые сервисы могут появиться, просто начав подписываться на нужные потоки, без изменения кода источника.

Пример choreography-based saga на Kafka Streams

// Order Service
KStream<String, Order> orders = builder.stream("orders");
orders
    .filter((k, o) -> o.getStatus() == CREATED)
    .mapValues(o -> new InventoryReserveCommand(o.getOrderId(), o.getItems()))
    .to("inventory-commands");

// Inventory Service
KStream<String, InventoryReserveCommand> cmds = builder.stream("inventory-commands");
KStream<String, InventoryReserved>[] branches = cmds
    .mapValues(this::tryReserve)
    .branch(
        (k, r) -> r.isSuccess(),
        (k, r) -> !r.isSuccess()
    );
branches[0].to("inventory-events");    // success
branches[1].to("inventory-failures");  // triggers compensation

Здесь нет оркестратора. Каждый сервис сам решает, как реагировать на успех или неудачу.

IIОркестровка: симфонический дирижёр

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

Оркестратор получает запрос на создание заказа. Он отправляет команду сервису инвентаря: «Зарезервируй товар». Получив подтверждение, он отправляет команду платёжному сервису: «Спиши средства». Если на любом этапе происходит сбой, оркестратор инициирует откат уже выполненных действий.

IIIСравнение и decision tree

Decision tree: что выбрать?

Процесс простой (< 4 шагов) и команды независимы?
    ├── Да → Хореография
    └── Нет ↓

Есть долгие таймеры (дни, недели) или human-in-the-loop?
    ├── Да → Workflow engine (Temporal, Camunda, DBOS)
    └── Нет ↓

Нужен централизованный контроль и компенсации?
    ├── Да → Orchestration-based Saga
    └── Нет → Гибрид: choreography на уровне домена + orchestration для сложных потоков

Практическое правило: хореография — для простых, стабильных процессов с 2–3 участниками. Оркестровка — для сложных, многошаговых процессов, где важен контроль, видимость статуса и возможность отката.

IVSaga: не третий паттерн, а реализация

В монолите мы привыкли к ACID-транзакциям: если один шаг упал, база данных откатит все изменения. В мире микросервисов у каждого сервиса своя база данных. Двухфазные коммиты (2PC) в распределённых системах работают плохо: блокируют ресурсы, убивают производительность и не масштабируются.

Saga разбивает большую бизнес-транзакцию на цепочку локальных транзакций. Каждая локальная транзакция обновляет свою БД и публикует событие, запускающее следующую. Главное правило: для каждого шага, который может быть отменён, должна быть предусмотрена компенсирующая транзакция.

VДва способа координации Saga

Choreography-based Saga

Каждый сервис слушает события и реагирует автономно. Нет центрального координатора. Подходит для 2–4 шагов.

Order Service ──OrderCreated──> Inventory Service
                                    │
                          InventoryReserved
                                    │
                                    ▼
                              Payment Service
                                    │
                          PaymentApproved
                                    │
                                    ▼
                              Shipping Service

Если платёж отклонён, PaymentFailed запускает обратную цепочку: Inventory → InventoryReleased → Order → OrderCancelled. Никто не координирует откат — каждый сервис сам знает, как реагировать на PaymentFailed.

Orchestration-based Saga

Центральный оркестратор управляет последовательностью шагов, принимает решения и координирует компенсации.

                    ┌──────────────┐
                    │  Saga        │
                    │  Orchestrator│
                    └──────┬───────┘
                           │
            ┌──────────────┼──────────────┐
            ▼              ▼              ▼
     ReserveInventory  ChargePayment  ShipOrder
            │              │              │
            ▼              ▼              ▼
         Success?       Success?       Done ✓
            │              │
         Yes │           No  │─── Compensate ──> ReleaseInventory
            │                                   ──> CancelOrder
            ▼
       Next step

VIТипология шагов Saga: pivot, compensable, retrievable

Не все шаги саги одинаковы. В литературе по Saga различают три типа:

Pivot-транзакция — точка, после которой откат невозможен, только компенсация. До pivot можно откатить всё. После pivot — только двигаться вперёд или компенсировать. Например, списание средств с карты — pivot: вернуть деньги можно только переводом, а не откатом транзакции.

VIIКак работает откат в Saga

Процесс: 1. Создать заказ → 2. Зарезервировать товар → 3. Списать деньги.

Если шаг 3 (списание денег) терпит неудачу, Saga инициирует «обратный танец»:

• Компенсирующий шаг 2: Снять резерв с товара (InventoryReservationCancelled).
• Компенсирующий шаг 1: Отменить заказ (OrderCancelled).

Компенсирующие шаги не отменяют факт совершения действий в прошлом (как ROLLBACK в SQL), а семантически инвертируют их результат, публикуя новые события.

VIIIИдемпотентность шагов и компенсаций

Каждый шаг саги может быть выполнен повторно. Сеть порвалась после выполнения, но до подтверждения. Оркестратор не получил ack и ретраит команду. Сервис получит команду дважды.

Если шаг не идемпотентен (balance += 100), повторное выполнение удвоит сумму — ровно то, что сага должна предотвращать.

Правила идемпотентности шагов Saga

1. Использовать saga_id + step_id как idempotency key. Сервис хранит таблицу обработанных команд: если (saga_id, step_id) уже обработан — вернуть предыдущий результат.
2. Upsert вместо insert. INSERT ... ON CONFLICT DO UPDATE вместо голого INSERT.
3. Внешние вызовы (платёжный шлюз) — передавать idempotency key в заголовке (Stripe, Adyen поддерживают это нативно).
4. Компенсации тоже должны быть идемпотентны. ReleaseInventory для уже освобождённого резерва должен вернуть success, а не ошибку.

Idempotency window: как долго хранить?

Таблица (saga_id, step_id) не может расти вечно. Практическое правило: хранить N дней (например, 30), где N превышает максимальное возможное время жизни саги + запас на retry.

-- Ежедневная очистка
DELETE FROM saga_idempotency
WHERE processed_at < NOW() - INTERVAL '30 days';

IXRetry strategies и circuit breaker

Не каждая ошибка — повод запускать компенсацию. Различают:

• Transient failures (сеть, таймаут, 503) — retry с backoff.
• Business failures (недостаточно средств, товар не найден) — компенсация.

Пример retry с exponential backoff + jitter

public <T> T retryWithBackoff(Supplier<T> action, int maxAttempts) {
    for (int attempt = 0; attempt < maxAttempts; attempt++) {
        try {
            return action.get();
        } catch (TransientException e) {
            long baseDelay = (long) Math.pow(2, attempt) * 100; // 100ms, 200ms, 400ms...
            long jitter = ThreadLocalRandom.current().nextLong(0, baseDelay / 2);
            Thread.sleep(baseDelay + jitter);
        }
    }
    throw new SagaCompensationException("Max retries exceeded");
}

Circuit breaker — после N неудач подряд перестать слать запросы на cooldown период. Это защищает перегруженный сервис от добивания и даёт ему время восстановиться.

XSemantic lock и его cleanup

ACID-транзакции дают изоляцию: параллельные транзакции не видят промежуточных состояний друг друга. Saga не даёт изоляции: другие сервисы могут увидеть «зарезервированный товар» до того, как платёж завершён.

Это создаёт аномалии изоляции:

• Lost update: две саги одновременно резервируют один товар — оба видят «доступно», один перезатирает другого.
• Dirty read: сервис аналитики видит «заказ оплачен», но платёж ещё не подтверждён.
• Non-repeatable read: два чтения одного состояния в течение саги дают разные результаты.

Решение — Semantic Lock. Сага помечает данные как «в обработке» через специальный статус:

-- Шаг саги: резервирование товара
UPDATE inventory
SET status = 'PENDING_SAGA',
    saga_id = 'saga-123',
    locked_at = NOW()
WHERE product_id = 42 AND status = 'AVAILABLE';

Другие саги не увидят этот товар как доступный. Semantic lock снимается в конце саги (success или compensation).

Cleanup застрявших semantic locks

Что если сага упала и не сняла semantic lock? Ресурс заблокирован навсегда. Решения:

1. TTL на lock. Поле locked_at + периодический cleanup job, который снимает locks старше N минут (например, 30 минут — максимальное время жизни саги + запас).
2. Heartbeat от оркестратора. Оркестратор периодически обновляет heartbeat_at в саге. Если heartbeat устарел — сага считается мёртвой, locks снимаются.
3. Explicit reconciliation job. Отдельный сервис, который сканирует активные саги и сверяет состояние с semantic locks. Обнаружив расхождение — инициирует компенсацию.

-- Cleanup job
UPDATE inventory
SET status = 'AVAILABLE',
    saga_id = NULL,
    locked_at = NULL
WHERE status = 'PENDING_SAGA'
  AND locked_at < NOW() - INTERVAL '30 minutes'
  AND saga_id NOT IN (SELECT saga_id FROM active_sagas);

XIDeadline и таймауты саги

Что делать, если шаг саги не отвечает? Сколько ждать? Как решить, что компенсировать?

Правила таймаутов:

1. Per-step timeout. Каждый шаг имеет свой таймаут (например, 30 секунд для вызова платёжного шлюза). По истечении — retry или компенсация.
2. Saga-level deadline. У саги есть общий дедлайн (например, 5 минут). Если дедлайн истёк — принудительная компенсация.
3. Long-running sagas. Для саг, которые длятся дни (например, ожидание подтверждения от внешней системы), таймеры хранятся персистентно в оркестраторе.

// Temporal: таймаут шага
ActivityOptions options = ActivityOptions.newBuilder()
    .setStartToCloseTimeout(Duration.ofSeconds(30))
    .setRetryOptions(RetryOptions.newBuilder()
        .setMaximumAttempts(3)
        .build())
    .build();

activities.chargePayment(request, options);

// Temporal: общий дедлайн workflow
Workflow.await(Duration.ofMinutes(5),
    () -> paymentCompleted || deadlineExceeded);

XIIOutbox в контексте Saga

Команды оркестратора и события сервисов должны публиковаться атомарно с изменением состояния. Иначе возникает Dual Write: БД обновлена, а событие потерялось — или наоборот.

Решение — Transactional Outbox (см. главу IV). При обработке шага саги сервис в одной транзакции:

1. Обновляет бизнес-состояние (inventory.status = 'RESERVED').
2. Записывает событие в outbox-таблицу (InventoryReserved).

Отдельный процесс (relay) забирает события из outbox и публикует их в Kafka. Это гарантирует, что состояние и событие никогда не разойдутся.

BEGIN TRANSACTION;

UPDATE inventory
SET status = 'RESERVED', saga_id = 'saga-123'
WHERE product_id = 42 AND status = 'AVAILABLE';

INSERT INTO outbox (topic, key, payload)
VALUES ('inventory-events', 'prod-42',
        '{"type":"InventoryReserved","saga_id":"saga-123"}');

COMMIT;

XIIICompensation ordering

В каком порядке выполнять компенсации?

Правило: если между шагами есть причинная зависимость (B зависит от результата A), компенсации выполняются в обратном порядке. Если шаги независимы — параллельно.

XIVProcess Manager и event sourcing

Простой оркестратор, живущий в памяти, — хрупкая конструкция. При рестарте приложения состояние саги теряется. Process Manager — это паттерн долгоживущего оркестратора, который персистентно хранит своё состояние и может восстановиться после сбоя.

Process Manager хранит:

• Текущее состояние процесса — на каком шаге, какие шаги выполнены.
• Correlation ID — связывает все события одной саги.
• Историю — результат каждого шага для аудита и восстановления.
• Таймеры — для таймаутов.

Saga и Event Sourcing — естественная пара

Event sourcing и Saga — естественное сочетание. Состояние саги = последовательность событий саги.

Saga Events (append-only log)
    ├── SagaStarted { saga_id, order_id }
    ├── InventoryReserved { saga_id, product_id }
    ├── PaymentCharged { saga_id, amount }
    ├── ShippingScheduled { saga_id, tracking }
    └── SagaCompleted { saga_id }

Текущее состояние саги материализуется из журнала: saga_id → current_step, status, history. Компенсация — это новые события (PaymentRefunded, InventoryReleased), а не удаление старых.

Пример Process Manager на Kafka Streams

KTable<String, SagaState> sagaStates = builder
    .stream("saga-events")
    .groupByKey()
    .aggregate(
        () -> new SagaState(),
        (sagaId, event, state) -> state.apply(event),
        Materialized.<String, SagaState, KeyValueStore<Bytes, byte[]>>as(
            "saga-state-store")
    );

// Восстановление после сбоя — автоматически из changelog
// Продолжение с последнего незавершённого шага

XVSaga versioning: обновление без потери активных саг

Как обновить логику саги, если в системе уже есть активные саги со старой версией? Простое обновление кода сломает их.

XVIБизнес-компенсации: когда техника бессильна

Не все процессы можно «откатить» технически. Авиакомпания продала больше билетов, чем мест (овербукинг). Платёж прошёл, посадочный талон выдан. Технический откат — забрать деньги и аннулировать билет в аэропорту — катастрофа для бизнеса и репутации.

Здесь вступают в силу бизнес-компенсации. Вместо технического отката Saga генерирует FlightOverbooked, который запускает другой, человеческий или полуавтоматический процесс:

• Служба поддержки получает уведомление.
• Клиенту предлагается альтернативный рейс.
• На счёт клиента зачисляются бонусные мили или voucher.

Human-in-the-loop

Если бизнес-компенсация требует участия человека, это моделируется через workflow engine с wait-for-signal:

// Temporal: ожидание ответа человека
Workflow.await(Duration.ofHours(24),
    () -> humanDecisionReceived);

if (humanDecisionReceived) {
    activities.proceedWithAlternative(decision);
} else {
    activities.autoCompensate();
}

Другие случаи бизнес-компенсаций

• Chargeback (банковский возврат): клиент оспаривает транзакцию. Компенсация — дебет счёта продавца через N дней.
• Частичный откат: из заказа на 10 позиций отменены 3. Компенсация — вернуть деньги за 3 позиции, не отменяя заказ полностью.
• Отложенный платёж: банковский перевод приходит через 2 дня. Сага ждёт подтверждения, а не откатывает сразу.

XVIIWorkflow engines: Temporal, Camunda, Step Functions

Построение оркестратора с нуля — сложная задача. На рынке есть зрелые workflow engines, которые берут на себя персистентность состояния, retry, таймауты и компенсации.

Пример саги на Temporal с встроенными compensations

public class OrderSagaWorkflowImpl implements OrderSagaWorkflow {
    private final Saga saga = new Saga(new Saga.Options.Builder()
        .setParallelCompensation(false)
        .build());

    @Override
    public void execute(OrderRequest request) {
        try {
            activities.reserveInventory(request);
            saga.addCompensation(activities::releaseInventory, request);

            activities.chargePayment(request);
            saga.addCompensation(activities::refundPayment, request);

            activities.shipOrder(request);
            // shipOrder — pivot: не имеет компенсации
        } catch (Exception e) {
            saga.compensate();  // автоматически в обратном порядке
            throw e;
        }
    }
}

Ключевое свойство Temporal — durable execution: если worker, выполняющий сагу, падает, другой worker подхватывает с того же шага. Состояние шагов и история вызовов сохраняются.

XVIIIConcurrent sagas и разрешение конфликтов

Два заказа на один и тот же товар. Кто первый забронировал? Без изоляции — race condition.

• Optimistic concurrency control. Каждый шаг саги проверяет версию данных. Если версия изменилась — откат с перезапуском саги.
• Pessimistic locking (semantic lock). Шаг «резервирование» немедленно блокирует товар (status = PENDING), предотвращая параллельные резервирования.
• Commutative operations. Если операции коммутативны (порядок не важен), конфликты не возникают. Например, добавление товаров в корзину — два add-а дают одинаковый результат.
• Saga ordering by priority. Для финансовых саг — упорядочивание по timestamp или priority queue.

XIXObservability бизнес-процессов

Как отследить статус конкретной саги в хореографии, где нет центрального координатора?

• Correlation ID — во всех событиях одной саги. Позволяет собрать цепочку событий в distributed tracing.
• Saga state store — отдельная таблица/БД, хранящая статус саги по saga_id. Обновляется каждым сервисом при выполнении шага.
• Dashboard — показывает все активные саги, их текущий шаг, возраст, статус (running, compensating, completed, failed).
• Alerting — сага, зависшая на одном шаге дольше N минут — алерт. Сага в статусе compensating дольше M минут — критический алерт.
• Distributed tracing — OpenTelemetry trace для каждой саги, span для каждого шага.

Метрики для мониторинга

XXЧеклисты и связь с циклом

Связь с предыдущими главами

Чеклист проектирования Saga

• Выбран способ координации: хореография, оркестровка или workflow engine (decision tree)
• Определены типы шагов: compensable / pivot / retrievable
• Для каждого compensable шага определена компенсация
• Все шаги и компенсации идемпотентны (saga_id + step_id как idempotency key)
• Idempotency window определён (N дней)
• Retry strategy настроена (exponential backoff + jitter)
• Circuit breaker настроен для внешних вызовов
• Semantic locks используются для изоляции
• TTL для semantic locks + cleanup job
• Per-step и saga-level таймауты настроены
• Публикация команд и событий через Transactional Outbox
• Compensation ordering определён (обратный порядок или параллельно)
• Process Manager персистентно хранит состояние
• Saga versioning: новые саги на новой версии, старые — на старой
• Бизнес-компенсации для случаев, где технический откат невозможен
• Human-in-the-loop через wait-for-signal (если нужно)
• Correlation ID во всех событиях саги
• Dashboard и алерты на зависшие саги
• Метрики: duration, stuck count, compensation rate, pivot failures

Глава VIII цикла «Событийно-управляемая архитектура». Источники: microservices.io, Temporal, Camunda, AWS Step Functions, Restate, DBOS, Marcustan, OpenTelemetry, практические кейсы production-систем.