I especially liked the point about observability being a key player while implementing Sagas. Without that, it can become really difficult to make sense of things when they go wrong in a Saga flow. We realized that pain in one project a few years back, where multiple teams ended up blaming each other without any clear indication of which service was causing a particular issue.
Orchestration makes this somewhat easier as you mentioned, but again it's better to use that mainly if all services are within the team and you don't have to ping 5 people to understand what's happening...lol.
Quick and easy to follow introduction to sagas, thank you very much 👍
Glad you found it helpful!
Sagas can be a tricky topic, so I aimed to make it as clear and practical as possible.
Appreciate you reading.
Great explanation Raul.
I especially liked the point about observability being a key player while implementing Sagas. Without that, it can become really difficult to make sense of things when they go wrong in a Saga flow. We realized that pain in one project a few years back, where multiple teams ended up blaming each other without any clear indication of which service was causing a particular issue.
Orchestration makes this somewhat easier as you mentioned, but again it's better to use that mainly if all services are within the team and you don't have to ping 5 people to understand what's happening...lol.
Haha yes, that “who owns what” finger-pointing loop is all too familiar 😅.
Observability really is the glue that holds sagas together when things go sideways.
Orchestration can bring some clarity, but only if the team boundaries align. Otherwise, it just becomes another coordination overhead.
Appreciate you sharing that real-world pain, it’s exactly the kind of thing we need to talk about more!