In recent times, the design of software architectures based on microservices has become very important. And although at first, they can solve and help in many problems, they also carry some others, such as maintaining the integrity of data. To solve and guide in this type of problems, we have created this article “Saga Pattern in Microservices Architecture“.

In this article, we are going to guide this design pattern to two types of microservices architecture, choreography and orchestration. So, if you are not clear about what they mean, we recommend taking a look at this article.

Let’s go to deep in Saga Pattern in Microservices Architecture.

Some Design Patterns in Microservices Oriented to Data

In microservices-oriented architecture, as we have to decouple the relationship between the different components as much as possible, one of the biggest challenges we face is how to maintain data consistency. To achieve this, there are different design patterns that will be applied to work with data management, depending on the needs of each moment, whether it is an architecture that starts from scratch or if it is a migration, for example, from a monolithic architecture to a microservices-oriented one. Among these design patterns, we can find:

CQRS

This design pattern, whose acronym in English means Command Query Responsibility Segregation, separates command and query responsibilities over data. Conceived by Bertrand_Meyer, the idea that arises from this pattern is that each microservice should perform a command that performs an action or a query, but not both. One could have a database for read operations and another for write/update operations.

Event Sourcing

This design pattern is very common to find integrated with CQRS. The use of this pattern would work by sending messages asynchronously between microservices, for example, using Kafka for communication between them.

Database per Service

In a microservices architecture, each service should be as decoupled as possible. Therefore, maintaining a common database could be complex and challenging. Independent scaling of different databases according to specific needs and preserving isolation of some operations that require consultation with others is necessary.

You can use different database types such as column-oriented or graph-oriented databases because different microservices have varying requirements.

Transaction Log Tailing

This is another pattern to help achieve distributed transactions. The idea behind this pattern is to track transaction records in the database and publish each change as an event.

Saga

This pattern, which is the subject of our article Microservices Architecture: Saga Pattern, could be described as a sequence of transactions through some type of event. We’ll delve deeper into this in the next section.

What is the Saga Pattern?

Let’s first look at a small example to try to understand it better.

We have an online store, in which each customer pays for virtual money to spend in the store. With each order, we have to ensure that the customer has enough money to make that payment. As we’ve seen, our transactions cannot be ACID, since our architecture has two microservices with a database per service, and transactions will depend on multiple services.

Therefore, in our architecture, we’ll encounter the problem of how to deal with transactions that depend on other services. We could define Saga as a sequence of local transactions, in which each local transaction updates the next transaction to be performed through some type of event. If a transaction fails, then the saga must execute a series of transactions to undo the changes that were made and leave all the information in a consistent state, i.e., it must perform a compensation.

Saga is present in two microservice designs: Choreography and Orchestration.

Saga Pattern with Orchestration

In microservices, orchestration can be defined as an architecture where a coordinator manages the transactions to be executed. Using a music orchestra analogy, you’d have musicians coordinated by the conductor.

Based on the example we discussed earlier, let’s create an orchestration architecture. In our store, we have two microservices, Order Service and Client Service. Each has its own database. The process would be a customer places an order (Order Service), and an event is sent to the Client Service to check if they have enough balance.

Let’s look at the flow of an order:

The above diagram shows the flow of a customer order with an orchestrator between the microservices. As you can see, the piece responsible for directing all calls between the microservices is the orchestrator.

Flow:

1. The customer places an order.
2. The service saves the “pending confirmation” state in the database.
3. The order service makes a request to the orchestrator to start the transaction.
4. The orchestrator sends a request to update the client’s balance.
5. The service updates the client’s balance in the database.
6. The orchestrator receives information about the client’s available balance.
7. The orchestrator sends the response to the order service.
8. The order service updates the state to “order sent.”

This is the “happy path” of an order, but what if the customer doesn’t have enough balance? A rollback would have to be performed, which, having an orchestrator, would be relatively straightforward. Essentially, the client service would return “Insufficient balance,” and the registration state would have to be changed to “fail” in the flow.

Rollback in an orchestration with Saga

In our store, it happens that the customer does not have enough balance to pay for the item. So we are going to implement a rollback or compensation system in our orchestration architecture, and in our case, in the flow, points 6, 7, and 8 would change.

• 6.- The system sends a message indicating that the user’s balance is insufficient.
• 7.- The orchestrator sends the response to the requested service with the insufficient balance.
• 8.-The order service updates the status to “insufficient balance.”

As we have seen, performing a rollback or compensation with a Saga pattern in orchestration is quite simple to achieve.

Advantages and disadvantages of using the Saga pattern in orchestration

We can easily understand the flow that each transaction will take by implementing orchestration, as the “orchestrator” serves as the central piece connecting each service. Additionally, implementing orchestration ensures that transaction complexity remains linear and avoids cyclic dependencies.

All of this is achieved thanks to a central piece that orchestrates the entire architecture (could be the conductor), but if this piece contains a lot of logic, its maintenance will become more complex.

Saga Pattern with Choreography

In a choreography, each dancer functions independently, performing a sequence of steps that are framed within a system to achieve a goal together. With this analogy, we could define choreography in Software Architecture, in which each service or microservice will communicate with others through events to decide the next action to take.

In contrast to orchestration, we do not have a central piece that “orchestrates” the next action or step, but rather events are sent, which in this case will be processed, for example, by Kafka.

With a Saga pattern, an ID for each transaction will be crucial so that when events are sent, all services listening will always know which transaction they correspond to.

The process or flow that will be followed from when a customer makes a request will be as follows:

1. The customer places an order.
2. The service saves the status “pending confirmation” in the database.
3. The order service makes a request through a message.
4. The client service listens to the request and saves the client’s balance update in the database.
5. The service sends a message with the available balance.
6. The order service analyzes the received message, which reports that the client has sufficient balance.
7. The database is updated, and the order is sent.

This would be the normal process of fulfilling a customer’s order, but what would happen in a choreography if the customer does not have enough balance? Let’s see.

Rollback in a Choreography with Saga

The previous process would be the typical process in which everything has gone well, but just as it happened with the example in orchestration, what would be the compensation if our client does not have sufficient balance?

Compensation in a choreography is more complex than with orchestration, unless the flow is similar to our 7-step example. The more steps our flow has, the more complex it is to perform a compensation system.

The steps that would be taken to roll back our choreography example in the case where the customer does not have enough balance are shown below:

6. The system sends a message to a Kafka broker indicating that the user’s balance is insufficient.
7. The Order Service receives that message and updates the status to “insufficient balance.”

Advantages and disadvantages of using the Saga pattern in Choreography

Implementing a Saga pattern in a choreography is quite simple. Each service will depend on another that it has communicated with through some type of event to carry out a transaction. Up to this point, it is quite easy, and this system will work very well with architectures that have few transactions, as in our example.

But what will happen with systems that have many transactions? Imagine having more than 15 steps to manage your transactions. In that case, it would be very complex to know which services will listen or receive which events, and implementing a compensation system would be even more complex.

Conclusion

In this article about “Saga Pattern in Microservices Architecture“, we have seen this pattern as a Orchestration and Choreography.

We have seen their Pros and Cons. with their Pros and Cons.

To apply one scenario or the other, you must consider the use case that needs to be solved, and the number of transactions.