Saga Pattern #1: What is it?
Se preferir, você pode ler esse artigo em Português aqui
While ago when life was simpler and it was all about monoliths, guaranteeing data consistency was easier due to the fact that we could trust ACID transactions.
💡 Atomicity, Consistency, Isolation, and Durability (ACID) are properties that assure data consistency within a single data source
However, after the rise of microservices, guaranteeing data consistency within transactions that span multiple services and distinct data sources became challeging and this is where the Saga pattern comes in handy.
We can understand sagas as a set of business workflows that affect data in multiple services. Each saga corresponds to a sequence of local transactions executed within a single service and this sequence is coordinated via messaging.
What? Business workflows? Services? Local transactions? 😰
Chill out, I’m gonna explain it better!
Saga Pattern
Suppose we’re back in time directly to 2009 and urban traffic still depends on taxis. One day, someone had a brilliant idea: why not simplify passenger and driver lives with an app? From this idea, an application was born with several cool features…
What if the passenger could ask for a trip and find the closest driver?
How about allowing payments to be made using a virtual wallet?
Wouldn’t rewarding users increase the amount of trips requested?
Comparing with sagas concept, we can understand each one of these features as a business workflow. Thinking this way, requesting trips, paying using a virtual wallet, and rewarding users are business workflows and can be defined as sagas.
Moreover, each saga depends on multiple services and these services are considered sagas participants. Take a look on the steps required for the trip to take place:
Analyzing the previous image, wouldn’t make sense to say that choosing a route and paying are features from distinct services? We could use, for example, Google Maps API to handle geospatial information while the payment requires interactions with financial market specific APIs. Furthermore, finding the most suitable drivers isn’t trivial due to the fact that they’re part of the users base and also a geospatial coordinate. Therefore, it does make sense to say that the business workflow to request a trip depends on three services/participants: route, driver, and payment.
Right, but where do local transactions fit into all this? 🤔
Even though the workflow depends on three services, each one is independent, meaning that each service can have its own database and this is where local transactions come in place. As each service has its own database, every action performed within the same service is a local transaction and can benefit from ACID transactions.
The following image illustrates the saga to request a trip and its local transactions.
Business workflow is saga, service is a saga participant, and local transaction is an action executed in a service, is that it? 😎
Yeah, but that’s not all… Unfortunately, we can have problems with the trip. Suppose that there are no drivers near the passenger, looks like impossible right? But it isn’t and we need to take care of such edge case. In order to make it possible, for each local transaction that updates a database, there is a compensating transaction responsible for undoing the changes.
Ok, now we need to dive deep on how each saga’s local transaction is triggered and for that we use a process named sagas coordination.
Sagas Coordination
In the sagas world, local transactions are triggered using messaging: after each local transaction is executed, a message is published informing that some action was performed successfully and the next can be triggered. Similarly, when a business rules violation occurs while executing a local transaction, a message must also be published in order to trigger the necessary compensating transactions.
An important term here is trigger: each local transaction act according to the event received, but who coordinate these triggers? In general, we can categorize the sagas coordination into two main types: choreography and orchestration.
Choreography
Sagas coordination through choreography is like a dance: each participant knows their steps and knows how to react to the steps of their partners without the need for someone guiding them.
When using this type of coordination, each saga participant subscribes to the events of interest and act according to the events that has subscribed to.
The main advantage of choreography is simplicity: there’s no need to define a central point responsible for coordinating the sagas and each participant receives the events that has subscribed to.
However, as disadvantages, we have the risk of acopling the participants, given that each one has to subscribe to all events of interest. Therefore, as the number of participants increases, the number of subscriptions and complexity will also increase.
Orchestration
On the other hand, sagas coordination through orchestration, like the name indicates, is more like an orchestra that has someone guiding the musicians.
When using this type of coordination, an orchestrator is responsible for sending the events that triggers the participants and also receving the events of answer when some action is executed. According to the answers, the orchestrator knows which action must be triggered next, whether this action is to trigger the next saga participant or start the compensating transactions. Thus, each participant is only responsible for its own event channel and doesn’t need to subscribe to other channels.
The main advantage of orchestration is the separation of concerns between saga participants, given that the logic responsible for triggering the actions is centralized in the orchestrator.
Yet, this approach adds complexity by including another possible point of failure: the orchestrator. Usually, this approach is more recommended in case of a saga with multiple participants and communications channels.
Wow! We’re done, right? Right??? 🤯
I hate to tell you, but no… If you really got the ACID transactions concept, then you might have noticed that the Saga pattern lacks one property: isolation. However, we can handle this subject in another article, for today we’re done, see you later! 😉
