Эта глава темы 9 фокусируется на оркестрации workflow, compensation и идемпотентной обработке шагов.
В реальном проектировании систем материал помогает принимать решения через измеримые ограничения: latency budget, blast radius, устойчивость контрактов и стоимость эксплуатации интеграции.
Для system design interview глава дает структурный язык объяснения: почему выбран подход, какие альтернативы рассматривались и какие operational риски надо фиксировать заранее.
Практическая польза главы
Практика проектирования
Проектируйте long-running процессы с явными шагами компенсации и ownership состояния.
Качество решений
Сравнивайте orchestration и choreography по прозрачноcти управления и сложности эволюции.
Interview articulation
На интервью структурируйте saga-кейс через happy path, failure path и recovery policy.
Failure framing
Задавайте timeout/retry limits, чтобы workflow не зависали и не дублировали действия.
Primary source
Temporal Workflows
Базовая модель durable execution и workflow semantics.
Workflow orchestration - это отдельный архитектурный слой для управления долгоживущими бизнес-процессами между микросервисами. Он централизует состояние процесса, retry/timeout-политики, компенсации и операционный контроль исполнения.
Сигналы, что оркестрация действительно нужна
Процесс длится минуты, часы или дни
Когда бизнес-флоу выходит за пределы одного HTTP-запроса, нужен durable state и возможность безопасно продолжить выполнение после сбоя.
Есть компенсации и rollback-сценарии
Если шаги затрагивают несколько сервисов, оркестратор упрощает реализацию Saga-подхода: явные компенсации, порядок откатов и прозрачная история действий.
Нужны стандартизированные retry/timeout-политики
Единые правила повторов, backoff и дедлайнов уменьшают дублирование инфраструктурного кода в каждом сервисе.
Важен операционный контроль
Нужны replay, ручной restart шага, pause/resume, аудит и метрики по состояниям workflow в одном контуре наблюдаемости.
Temporal, Cadence, Step Functions: практическое сравнение
| Платформа | Модель состояния | Модель разработки | Retry/timeout | Trade-offs |
|---|---|---|---|---|
| Temporal | Durable execution + event history | Code-first workflow в SDK (Go/Java/TS/...) | Политики retry на activity/workflow + timers | Нужна deterministic дисциплина и отдельный operational контур. |
| Cadence | Durable execution (архитектурно близко к Temporal) | Code-first workflow в SDK | Activity retry policies и контроль через domain settings | Чаще выбирается в существующих инсталляциях и миграционных сценариях. |
| AWS Step Functions | Managed state machine (ASL, визуальные состояния) | Декларативные state-машины + AWS-интеграции | Retry/Catch на уровне состояний | Сильная интеграция с AWS, но выше риск vendor lock-in. |
Эталонный флоу с компенсациями
Типовой заказной процесс: резервируем товар, списываем оплату, создаём отгрузку, отправляем подтверждение. При сбое выполняем компенсации в обратном порядке.
Эталонный процесс оркестрации
Happy path и компенсации Saga в одном визуальном флоу.
export async function OrderWorkflow(input: OrderInput): Promise<void> {
const reservation = await reserveInventory(input.orderId, input.items);
try {
await chargePayment(input.orderId, input.amount);
await createShipment(input.orderId, reservation.warehouseId);
await sendConfirmation(input.orderId);
} catch (error) {
await refundPayment(input.orderId);
await releaseInventory(input.orderId);
throw error;
}
}Контракт выполнения и эксплуатационный чеклист
Execution contract
- Идемпотентность каждого activity: повторный запуск шага не должен нарушать бизнес-состояние.
- Явные timeout/deadline для каждого внешнего вызова и для workflow целиком.
- Компенсации должны быть бизнес-эквивалентны действию, а не только техническим rollback.
- Версионирование workflow-логики: старые инстансы продолжают работать по старым правилам.
- Каждое состояние workflow должно быть наблюдаемым через метрики и трассировку.
Reliability checklist
- У каждого workflow есть стабильный business key (например, `orderId`) и dedup policy.
- Activity не содержит скрытых nondeterministic вызовов без обертки в side-effect primitive.
- Ошибки разделены на retryable и non-retryable с разной политикой реакции.
- Ручные операции (`resume`, `terminate`, `retry from failed step`) описаны как runbook.
- SLO оркестрации измеряется отдельно: start latency, completion latency, failure rate.
Риски реализации
Смешивание бизнес-логики и transport-деталей
Держите workflow как слой координации, а доменные решения и внешние интеграции выносите в отдельные activity/handler слои.
Неявные компенсации
Определяйте компенсации рядом с каждым шагом и тестируйте их отдельно в fault-инъекциях.
Один гигантский workflow
Декомпозируйте флоу на под-процессы с чёткими входами/выходами и bounded context ownership.
Недостаточная observability
Публикуйте метрики по статусам шагов, retry depth, queue lag и времени до завершения.
References
Связанные главы
- Паттерны межсервисной коммуникации - Базовый контекст sync/async взаимодействий и границ между сервисами.
- Distributed Transactions: 2PC и 3PC - Контекст распределённых транзакций и причин, почему Saga часто предпочтительнее 2PC.
- Event-Driven Architecture: Event Sourcing, CQRS, Saga - Сопоставление orchestration и choreography в событийных системах.
- Service Discovery - Стабильный routing и service lookup для шагов workflow между сервисами.
- Паттерны отказоустойчивости: Circuit Breaker, Bulkhead, Retry - Практики деградации и управления сбоями на уровне каждого шага процесса.