Ото ж цей день настає в кожного хто працює з мікросервісами - нам потрібно досягти транзакційного збереження даних між сервісами. Перше що слід зробити - це переглянути межі сервісу й подумати чи не накосячили ми з межами й чи не слід нам їх розширити. Но так ми й до моноліту можемо допереглядатися. Наступне що нам часто приходить в голову - це бути як база даних та імплементувати 2 фазний коміт чи якщо ми говоримо про мікросервіси, то скоріше що нам треба покращений 3 фазний варіант якій забезпечує відновлення процесу при падінні оркестратора. Так правда ніхто не робить, бо це дуже повільно й геморно й сильно зв'язано.

Відповідями на нашу проблему є saga

Software Architecture: The Hard Parts: Modern Tradeoff Analysis for Distributed Architectures (https://www.amazon.de/-/en/Neal-Ford/dp/1492086894/ref=sr_1_1?crid=24OVLTJGSANE5&keywords=tradeoffs&qid=1650127250&sprefix=tradeoffs%2Caps%2C83&sr=8-1) досить класно та ґрунтовно описує 8 основних патернів sag базуючись на 3 бінарних характеристиках

• комунікація - синхронна / асинхронна
• консистенція даних - атомарна / евентуально
• координація - оркестрована (є центральний гравець) / хореографована (сервіси домовляються між собою самі) Тому саг є значно більше й зазвичай фреймворки часто імплементують оркестровану синхрону сагу з лінійним набором кроків Власне поговоримо про це https://www.youtube.com/watch?v=-O5G26i8_gM