Documentation

The saga pattern is a failure management pattern that helps establish consistency in distributed applications, and coordinates transactions between multiple services to attempt to maintain data consistency.

If you’re wondering if the saga pattern is right for your scenario, ask yourself:

Does your logic involve multiple steps, some of which span machines, services, shards, or databases, for which partial execution is undesirable?

Turns out, this is exactly where sagas are useful. Maybe you are checking inventory, charging a user’s credit card, and then fulfilling the order. Maybe you are managing a supply chain.

The saga pattern is helpful because it basically functions as a state machine storing program progress, preventing multiple credit card charges, reverting if necessary, and knowing exactly how to safely resume in a consistent state in the event of power loss.

There are many “do it all, or don’t bother” software applications in the real-world:

• If you successfully charge the user for an item but your fulfillment service reports that the item is out of stock, you’re going to have upset users if you don’t refund the charge. If you have the opposite problem and accidentally deliver items “for free,” you’ll be out of business.
• If the machine coordinating a machine learning data processing pipeline crashes but the follower machines carry on processing the data with nowhere to report their data to, you may have a very expensive compute resources bill on your hands.

In all of these cases having some sort of “progress tracking” and compensation code to deal with these “do-it-all-or-don’t-do-any-of-it” tasks is exactly what the saga pattern provides. In saga parlance, these sorts of “all or nothing” tasks are called long-running transactions. This doesn’t necessarily mean such actions run for a “long” time, just that they require more steps in logical time than something running locally interacting with a single database.

A saga is composed of two parts:

1. Defined behavior for “going backwards” if you need to “undo” something (i.e., compensations)
2. Behavior for striving towards forward progress (i.e., saving state to know where to recover from in the face of failure). This second part is often called the “orchestration logic” of the saga. For Temporal, execution of the orchestration logic is handled by the Temporal server, and the saga monad transformer here simply needs to handle the compensation logic.

Lastly, note that compensation actions are still subject to the same restrictions as any other workflow code. This means that compensation Actions run within a Workflow monad can be timed out, and they can be retried. Make sure in this case that whatever retry / timeout policies you have in place for your workflow are appropriate for the compensation actions you are running.

For more information on the saga pattern, see the following resources:

• Saga Pattern Made Easy
• The Saga Pattern in Distributed Systems