Ото ж цей день настає в кожного хто працює з мікросервісами - нам потрібно досягти транзакційного збереження даних між сервісами.
Перше що слід зробити - це переглянути межі сервісу й подумати чи не накосячили ми з межами й чи не слід нам їх розширити. Но так ми й до моноліту можемо допереглядатися.
Наступне що нам часто приходить в голову - це бути як база даних та імплементувати 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
розгорнути опис
згорнути опис
