The pros and cons of the Saga architecture pattern

Having a grasp of common architectural patterns is essential to designing software architecture at scale. Using them saves not only time but also ensures a reliable implementation of your design. There’s no need to reinvent the wheel when there’s an architectural pattern available that applies to an architecture you’re developing.

The following is a brief overview of the Saga architectural pattern.

Understanding the Saga pattern

The Saga pattern is one in which the steps of a transaction are chronicled according to a set of predefined actions. This chronicle is called a saga. As each step in a transaction is executed, a controller service compares the result of the step against the saga definition. If a step is executed successfully, the next step in the saga is executed. Should a step fail, all the steps defined in the saga are set back to the last known good state.

The Saga pattern is well-suited to transactions that execute over various independent, loosely coupled services in which each service is hosted at a separate location.

Image

Pros

• Makes transaction management in a loosely coupled, message-driven environment possible.
• Well-suited to transactions that have a small number of steps (4 -5).

Cons

• Can be complex to manage, particularly if a transaction has a large number of steps and the environment is asynchronous.
• Requires a good deal of programming, particularly to support rollback in an asynchronous, message-driven environment.

Putting it all together

Handling a transaction that occurs over a large number of loosely coupled or independent services is a difficult undertaking. It’s even more difficult when the transaction occurs in systems that use asynchronous communication. The Saga pattern addresses the issues head-on.

Basically, the pattern describes how a transaction is supposed to go. A controller will execute these steps among a variety of services. Should a step fail, the controller will restore all the services affected by the transaction back to the last known good state.

The Saga pattern can be difficult to implement, particularly in an asynchronous environment. But the safety it provides makes it worth the efforts required to implement the pattern.