Приходилось ли работать с паттерном сага
Что проверяют
Понимаете ли вы, что сага это способ описать процесс, у которого нет общего отката. Для аналитика проверка в том, сумеете ли вы задать компенсации, состояния и видимое пользователю поведение, а не пересказать определение из статьи.
Как отвечать
Сага это цепочка локальных транзакций в разных сервисах, где у каждого шага есть компенсирующее действие на случай отказа следующего. Два стиля:
- хореография: сервисы обмениваются событиями, координатора нет, процесс расползается по коду, и на вопрос «где застрял заказ» никто не отвечает без чтения логов;
- оркестрация: отдельный координатор хранит состояние процесса и вызывает шаги, такой процесс проще рисовать, сопровождать и показывать поддержке.
От аналитика ждут таблицу: шаг, условие успеха, компенсация, таймаут, что в этот момент видит клиент. Подчеркните, что компенсация это не откат: списанные деньги возвращают новой операцией, отправленное письмо не отзывается, поэтому вместо списания товара делают резерв, который легко снять.
Скажите и про изоляцию, точнее про её отсутствие: пока сага идёт, промежуточное состояние видно другим процессам. Отсюда в требованиях появляется статус вида «заказ оформляется», срок его жизни и отдельный сценарий ручного разбора, когда компенсация не прошла.
Где спотыкаются
Называют сагу распределённой транзакцией. Атомарность тут только в конечном счёте, изоляции нет вовсе, и на этом ограничении держится половина требований к интерфейсу и отчётности.
Второе: описывают удачный сценарий и добавляют строчку «при ошибке откатываем». Отдельного решения требуют два случая: упала сама компенсация и повторился шаг, который уже выполнился. Без идемпотентности повтор спишет деньги дважды.
Третье: выбирают хореографию, потому что она выглядит проще на схеме из трёх сервисов. Через полгода шагов становится десять, порядок событий неочевиден, и восстановить картину процесса можно только по логам всех участников.