The SAGA Design Pattern Explained in 6 MINUTES | Orchestration vs Choreography

In traditional monolithic applications, transactions are managed by a single database, ensuring the ACID properties.

Atomicity ensures that a transaction is treated as a single unit of work, either fully completed or not at all. If any part of the transaction fails, the entire transaction is rolled back to its previous state.

Consistency ensures that the database remains in a valid state after a transaction, meaning that any constraints or rules defined for the database are not violated.

Isolation ensures that concurrent transactions do not interfere with each other, and that each transaction sees the database as if it were the only one accessing it.

Durability ensures that once a transaction is committed, its changes are permanent and will survive any subsequent failures, such as power outages or system crashes.

The Saga is a design pattern that decomposes a long-lived transaction into a series of smaller transactions distributed across multiple processes. It also guarantees that either all transactions in a saga are successfully completed or compensating transactions are performed to amend a partial execution.

In its happy path, the transaction proceeds from one step to the next until completion. In case of a step failure, the Saga performs compensating actions in order to take the system back to its original state.

In the original paper by Hector Garcia-Molina written in 1987, the concept of long-lived transaction is tied to time and mostly a single relational database. Today, we can break away from the concept of time and consider as long-lived any transaction that involves more than one operation. Another thing I want to highlight is that Sagas are not specific to microservices. You can use them also in a monolith. Sagas are applicable any time you cannot create a single database transaction. For instance, your workflow might interleave database operations with invocation of other services. That’s a perfect fit for a Saga as well.

In terms of Domain Driven Design (DDD), the Saga is the perfect pattern when you have a business operation that spans across multiple bounded contexts.

📅 Let's have a 1:1 Call to discuss anything you wish 📅
topmate.io/marcolenzo

🤓 There's more on my website! (articles, scripts, code snippets, etc...): 🤓
marcolenzo.eu/

🤝 Connect with me: 🤝
www.linkedin.com/in/marcolenzo/

👌Get a CodeCrafter Discount 👌
app.codecrafters.io/join?via=marcolenzo

🍕 I've got an Italian accent 😅
If you have trouble understanding me, activate the closed captions! They are manually corrected.

Temporal Workflows: temporal.io/

#systemdesign #softwarearchitecture #softwaredevelopment