Распределённые системы
Саги: собери отказоустойчивую сагу заказа
Читать про компенсации и idempotency — не то же, что смотреть, как сага переживает kill процесса в худший момент. Собери небольшую сагу заказа на три сервиса, потом ломай её специально — вали шаги, передоставляй сообщения, крашь оркестратор посреди процесса — и докажи, что система всегда приходит в согласованное состояние.
Преврати модель юнита в работающую сагу: оркеструй три шага с локальными коммитами, напиши реальную обратную компенсацию для каждого, сделай каждый шаг и компенсацию идемпотентными под at-least-once, защитись от аномалии конкурентной саги и проверь всё внедрёнными сбоями, а не happy path.
Реализуй оркестрованную сагу заказа на три сервиса (order, payment, inventory) с durable-состоянием шагов, реальными компенсациями, идемпотентными handler'ами и одной контрмерой изоляции — затем продемонстрируй, что она приходит в согласованное конечное состояние при каждом внедрённом сбое.
- Таблица сценариев: для каждого внедрённого сбоя (падение шага, retry компенсации, дубль доставки, краш посреди саги) — зафиксированное конечное состояние всех трёх сервисов и pass/fail по инварианту согласованности.
- Логи или трасса, показывающие, что передоставленное сообщение списания обнаружено и пропущено — сервис payment записывает ровно одно списание на сагу.
- Доказательство, что оркестратор продолжается после kill: сага, упавшая посреди процесса, при рестарте либо завершается, либо полностью компенсируется, без осиротевшего резерва или списания.
- Короткий разбор, называющий для каждого шага его компенсацию и является ли она настоящим откатом или приближением, плюс одну аномалию изоляции, которую предотвращает твоя контрмера, и почему.
- Добавь политику таймаутов и ретраев с ограничением попыток к каждому шагу, затем dead-letter путь: шаг, исчерпавший ретраи, запускает компенсацию всей саги, — и покажи, что это работает при недоступном downstream-сервисе.
- Перепиши оркестрацию как choreography (сервисы реагируют на события без координатора) и напиши абзац, что стало сложнее — трассировка застрявшей саги, добавление шага, персист состояния долгого ожидания.
- Добавь шаг ручного одобрения, который может приостановить сагу на произвольное время, и покажи, что durable-состояние переживает полный рестарт всех сервисов, пока сага запаркована.
- Добавь job сверки, который сканирует саги, застрявшие в нетерминальном состоянии за пределами SLA, и либо до-гоняет, либо компенсирует их, имитируя on-call инструмент, который реально понадобится в проде.
Это сага, которую ты реально соберёшь в проде, в миниатюре: локальные коммиты без глобальной транзакции, реальная обратная компенсация для каждого шага, необратимый шаг последним, durable-прогресс, чтобы краш продолжился, а не осиротил работу, идемпотентные handler’ы, потому что доставка at-least-once, и одна контрмера изоляции уровня приложения для конкурентных саг. Доказать это внедрёнными сбоями — а не happy path — и есть то, что превращает «я читал про саги» в «я прогнал одну через отказ и видел, как она пришла к согласованности».