Сага - спосіб виконати бізнес-операцію, що охоплює кілька сервісів, без розподіленої транзакції. Операція розбивається на послідовність локальних транзакцій, кожна в своєму сервісі. Якщо крок не вдається, виконуються компенсуючі дії для вже виконаних кроків.
Приклад - оформлення замовлення:
1. Замовлення: створити (статус pending) компенсація: скасувати
2. Склад: зарезервувати товар компенсація: зняти резерв
3. Платежі: списати кошти компенсація: повернути кошти
4. Замовлення: підтвердити
Якщо оплата не пройшла (крок 3) - знімається резерв (компенсація 2) і скасовується замовлення (компенсація 1).
Компенсація - не відкат. Інші частини системи вже могли побачити проміжні стани (резерв товару, замовлення pending). Компенсація - нова бізнес-операція («повернути кошти»), а не магічне повернення в минуле.
Хореографія - кожен сервіс реагує на події інших:
OrderCreated → Склад резервує → StockReserved → Платежі списують → PaymentCompleted → Замовлення підтверджує
- плюси: немає центрального координатора, сервіси слабо зв'язані, просто для 2-3 кроків;
- мінуси: логіку процесу ніде не видно цілком - вона розподілена по слухачах; важко відповісти «на якому кроці зараз замовлення?»; ризик циклічних залежностей подій.
Оркестрація - окремий оркестратор (сервіс чи об'єкт процесу) керує кроками, надсилаючи команди й чекаючи відповідей:
Оркестратор: «Склад, зарезервуй» → OK → «Платежі, спиши» → помилка → «Склад, зніми резерв» → «Замовлення, скасуй»
- плюси: процес описаний в одному місці, стан саги зберігається явно, легко моніторити й змінювати;
- мінуси: оркестратор - додатковий компонент і ризик «знати забагато».
Що обов'язково для саг:
- ідемпотентність кроків і компенсацій - повідомлення можуть повторюватися;
- збереження стану саги для відновлення після збою;
- семантичні блокування - статус «pending», щоб інші процеси не працювали з незавершеними даними;
- компенсації, що теж можуть не вдатися - повтори й ручне втручання як останній рубіж;
- відсутність ізоляції: інші бачать проміжні стани - бізнес має погодитися з цим.
Інструменти: у межах Laravel - ланцюжки й пакети джоб (Bus::chain, Bus::batch) і явна модель стану процесу; для складних процесів - рушії робочих процесів (Temporal тощо).
Правило вибору: хореографія - для простих процесів з кількома кроками; оркестрація - для складних, де важлива видимість і керування процесом.