Long-running business processes<\/strong> Many business processes consist of several individual steps that span extended periods of time\u2014ranging from minutes to several hours. Traditional transaction models are unsuitable for such processes because they tie up system resources for extended periods and are prone to errors.<\/p>\n\n\n\n Fault tolerance without global locks<\/strong> Global transactions spanning multiple services require locking mechanisms that limit system availability. If a partial failure occurs, it is often unclear how to handle inconsistent intermediate states.<\/p>\n\n\n\n Asynchronous Communication<\/strong> In modern system architectures, communication between services is often asynchronous\u2014for example, via events or messages. This makes centralized flow control more difficult and increases the complexity of error handling.<\/p>\n\n\n\n The Saga Pattern was originally described in 1987 by Hector Garcia-Molina and Kenneth Salem as a transaction model for long-running processes within monolithic systems. The goal was to break down so-called long-lived transactions (LLTs) into several smaller, independent transactions. This was intended to optimize resource utilization in traditional database systems and reduce the risk of prolonged locks. Instead of a single, long-running transaction, the individual steps were to be executed atomically and, in the event of errors, rolled back through so-called compensation actions.<\/p>\n\n\n\n Today, the Saga Pattern has taken on new relevance\u2014particularly in the context of distributed systems and microservices architectures. The basic idea remains the same: an LLT is divided into several local transactions that are executed in an isolated and atomic manner. In contrast to classic two-phase commit (2PC) procedures, execution occurs sequentially. If an error occurs, the transactions that have already been executed are rolled back through defined compensation actions. This ensures that the consistency of the overall system is maintained even without global locks.<\/p>\n\n\n\n A distributed saga typically consists of four key components:<\/p>\n\n\n\n This structure makes it possible to map both long-running operations in monolithic applications and complex processes in distributed architectures in a consistent, fault-tolerant, and scalable manner.<\/p>\n\n\n\n Example: Flight booking with hotel and rental car<\/strong><\/p>\n\n\n\n 1. Transaction Step 1: Flight Booking<\/strong><\/p>\n\n\n\n 2. Transaction Step 2: Hotel Reservation<\/strong><\/p>\n\n\n\n 3. Step 3: Rental Car Reservation<\/strong><\/p>\n\n\n\n Procedure:<\/strong><\/p>\n\n\n\n Success Run: The Saga pattern offers a number of technical advantages\u2014particularly in the context of distributed systems. At the same time, however, it also imposes specific requirements on system architecture, error handling, and business logic.<\/p>\n\n\n\n Advantages:<\/strong><\/p>\n\n\n\n Disadvantages:<\/strong><\/p>\n\n\n\n The Saga Pattern offers a robust alternative to traditional transaction models in distributed system architectures. By eliminating global locks and centralized commit protocols, it improves scalability and availability\u2014especially in microservices-based applications. At the same time, it enables controlled error handling through clearly defined compensation paths and allows for the management of long-running business processes with many sub-steps.<\/p>\n\n\n\n Suitable Use Cases<\/strong><\/p>\n\n\n\n This pattern is particularly useful when:<\/p>\n\n\n\n Typical use cases include booking and payment processes, order fulfillment in e-commerce systems, and user onboarding processes that involve multiple subsystems. Sagas enable the implementation of distributed transactions without requiring all participating systems to be modified or deeply integrated at the same time. Compared to 2PC, this significantly reduces the effort required for interface design and coordination. This is particularly advantageous in early project phases or during external system integration.<\/p>\n\n\n\n When Its Use Is Not Recommended<\/strong><\/p>\n\n\n\n The Saga Pattern is not suitable for all scenarios. It is particularly not recommended when:<\/p>\n\n\n\n Particularly in security-critical applications\u2014such as in the financial sector or the healthcare industry\u2014failing to ensure immediate consistency and isolation can lead to unacceptable risks.<\/p>\n\n\n\n The Saga Pattern is a valuable tool for modern, distributed systems\u2014but it\u2019s not a surefire solution. Success depends heavily on how it\u2019s implemented. Those who use it must actively address the challenges of compensation, concurrency, and consistency. When used correctly, however, the pattern enables fault-tolerant, scalable, and transparently orchestrated processes in a microservices environment.<\/p>","protected":false},"excerpt":{"rendered":" In der modernen Softwareentwicklung \u2013 insbesondere bei verteilten Systemen und Microservices-Architekturen \u2013 sto\u00dfen klassische Transaktionsmodelle wie ACID schnell an ihre Grenzen. Wie lassen sich lang andauernde, \u00fcber mehrere Services verteilte Gesch\u00e4ftsprozesse dennoch konsistent gestalten, ohne Systemverf\u00fcgbarkeit oder Fehlertoleranz zu gef\u00e4hrden? Mit genau dieser Fragestellung hat sich unser interner Arbeitskreis \u201ePlattform\u201c befasst \u2013 und dabei das […]<\/p>\n","protected":false},"author":4,"featured_media":601,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[5],"tags":[],"class_list":["post-593","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-softwareentwicklung"],"acf":[],"yoast_head":"\nAn Overview of the Saga Pattern<\/h2>\n\n\n\n
\n
Individual actions that are performed locally within a service and do not require a global lock.<\/li>\n\n\n\n
Reversible actions that can be used to undo erroneous or inconsistent states.<\/li>\n\n\n\n
Either centrally through a coordinator service (orchestration) or decentrally through communication between the participating services (choreography).<\/li>\n\n\n\n
The current state of a saga is typically persisted\u2014for example, in a process table\u2014to ensure that errors are handled in a traceable manner and that the execution of the substeps is transparent.<\/li>\n<\/ul>\n\n\n\n\n
\n
\n
![\"\"](\"https:\/\/test.itsonix.eu\/wp-content\/uploads\/2026\/05\/Saga_01_deutsch.jpg\")
Error log: ![\"\"](\"https:\/\/test.itsonix.eu\/wp-content\/uploads\/2026\/05\/Saga_02_deutsch.jpg\")
<\/p>\n\n\n\nAdvantages and Disadvantages of the Saga Pattern<\/h2>\n\n\n\n
\n
By breaking transactions down into local ones, there is no longer a need for global locking mechanisms that span system boundaries.<\/li>\n\n\n\n
Sagas circumvent the complexity and liveness issues of classic two-phase commit (2PC) protocols. This increases system availability.<\/li>\n\n\n\n
Errors in sub-steps are not handled by a full rollback, but rather through explicitly modeled compensatory actions.<\/li>\n\n\n\n
The progress of the saga can be tracked using a persistent process table and, in the event of an error, can be resumed or reactivated as needed.<\/li>\n<\/ul>\n\n\n\n\n
Compensations must be designed on a case-by-case basis. They cannot be automatically derived from the forward transactions and require in-depth subject matter expertise.<\/li>\n\n\n\n
Parallel or competing sagas can cause race conditions and interference that cannot be resolved automatically.<\/li>\n\n\n\n
Intermediate states may be inconsistent across the system until all steps have been completed or compensated for. This is not acceptable for all use cases.<\/li>\n\n\n\n
There is no cross-process transaction isolation\u2014other processes may access inconsistent data before the saga is complete.<\/li>\n<\/ul>\n\n\n\nWhen It's Worth Using the Saga Pattern\u2014and When It Isn't<\/h2>\n\n\n\n
\n
\n
Our Conclusion<\/h2>\n\n\n\n