Итак, вместо транзакций используются несколько паттернов. Одни из популярных – Saga и Outbox.

Saga – цепочка компенсирующих действий

Идея простая – мы не пытаемся сделать всё атомарно, мы строим процесс как набор шагов.
Если шаг не удался, мы не откатываем всё в ноль, мы выполняем компенсирующие действия.

Например:
• Создали заказ
• Списали оплату
• Зарезервировали товар
❌ Не удалось отправить в складскую систему

Что делаем?

Не откатываем всё назад, а:
• отменяем резерв
• возвращаем деньги
• помечаем заказ как отменённый

Это и есть saga — управляемый процесс с компенсациями.

Важно! Компенсация не равно откат в классическом смысле, это отдельная бизнес-операция.

Outbox – гарантированная доставка событий

Теперь другая ситуация: система говорит «заказ создан – отправим событие»

Но между записью в базу и отправкой события в брокер есть риск расхождения.

Например, заказ в БД есть, а событие в очередь не ушло (упал сервис)

И вот тут появляется outbox-паттерн, вместо того чтобы сразу отправлять событие, мы:
1. пишем заказ в БД
2. пишем событие в таблицу outbox
3. отдельный процесс читает outbox и публикует события

То есть БД становится источником истины и для данных, и для событий.

Почему системному аналитику важно в этом разбираться?

Потому что аналитик в такой системе уже не просто описывает, что «нажал кнопку – вызвали API – получили ответ», а он начинает проектировать:
• где шаги процесса,
• где возможны сбои,
• что будет при частичном выполнении,
• как выглядит компенсация,
• какие данные являются источником истины,
• что можно переиграть, а что нельзя.

Если упростить всё до одной мысли:
• в монолите мы боремся за атомарность
• в распределённых системах за устойчивость процесса

И именно поэтому появляются event-driven, retry с ограничениями, saga,
outbox – на самом деле это просто попытка сделать нестабильный мир управляемым.