Member-only story
Impossible Patterns | Love-Hate of SAGA Pattern & Lost art of XA.
Developers are inherently optimistic (say, less code), and the complexity of modern distributed architectures continues to make it impossible to motivate software engineers to pause and think about cascading failures.
In the context of Microservices, SaaS, Back-end for Front-end, and Supergraphs, you never know how many HTTP calls make up a ‘unit of work’.
It might as well be a black box.
Pre-dot-com (say, client-server), we were taught to count the beans EXACTLY, make sure we have databases and other resources (e.g., Queuing systems) that support XA, and write code that constitutes a unit of work as an atomic transaction. If you are on the financial services transactions teams’, you are probably still doing this.
Post-dot-com (say, n-tier/web), we were still very cautious about writing services that span a unit of work. Even in the world of SOAP and RPC, we were trying to minimize the risk of compensating transactions by leveraging federated XA, or excellent tools such as Atomikos.
When (internet) scaling became a problem, and cloud service providers offered database solutions — we have database systems and other resources (e.g., AMQP, Kafka, NoSQL), we have entirely moved away from XA. Very little or no cloud service provider…
