SAGA — это мощный паттерн, но он сильно усложняет систему. Не тащи его в проект без реальной необходимости.
Стоит использовать, когда
- Нужна согласованность данных в микросервисной архитектуре, где базы данных изолированы.
- Длинный бизнес-процесс можно разбить на независимые шаги.
- Есть возможность создать компенсирующие транзакции для каждого шага (отмена брони, возврат средств).
- Бизнес готов смириться с Eventual Consistency (согласованностью в конечном счете) и тем, что данные обновляются не мгновенно.
Не стоит использовать, когда
- Нужна строгая ACID-согласованность и мгновенный ответ (в таких случаях лучше подумать о монолите или единой БД).
- Сложно или невозможно создать компенсирующие операции.
- Система простая (вы тратите больше времени на поддержку Саги, чем на фичи).
Антипаттерн: Не используй SAGA для операций с внешними платежными шлюзами, которые не поддерживают программный возврат средств. Если ты списал деньги, а следующий шаг Саги упал — ты не сможешь сделать компенсирующую транзакцию для возврата. В таких случаях выноси оплату в самый конец процесса (как Pivot-транзакцию) или проверяй все условия ДО списания.