Microservice Using Saga Pattern

What is the Saga pattern in Microservice?

Saga Pattern basics are discussed, and different types of sagas and challenges are associated with using this pattern.

A microservices data management pattern known as the Saga Pattern is one of six important data management patterns. The Saga Pattern is, at its core, a direct offshoot of the database-per-service architecture.

Because each microservice is in charge of its own database, this design pattern is called database-per-service. On the other hand, this results in an intriguing circumstance. Which microservices will be affected by the presence of a transaction involving data from various sources?

That’s why the Saga Pattern is necessary.

What Is the Saga Pattern?

An architectural pattern for microservices called the Saga Pattern is used to implement transactions that span across several of these services.

If there are many local transactions, there will be many stories in the saga. This services each carry out a transaction and publish an event on their own. Other services keep an ear out for that and execute the next local transaction based on what they hear. This also executes compensating transactions to undo previous transactions’ effects if one transaction fails for some reason.

Let’s take a glance at a typical food delivery app to see how this works in practice.

Following is an example of what might happen after a customer places an order.

• The food delivery service creates an order. The order’s status is currently listed as PENDING. this is in charge of keeping track of everything that happens.
• This gets in touch with the restaurant through the restaurant’s customer service department.
• Customer service tries to place the order with the selected restaurant. The order is unsuccessfully placed. It replies once it has received confirmation.
• This has a response. Order approval or rejection will be based on the response.
• Next, the food delivery service makes a modification to your order. If the order were approved, the customer would be notified and given the following information. If the order is rejected, an apology message will be sent to the customer.

This approach has replaced the point-to-point call approach used in most workflows.

Different types of Sagas 

Generally speaking, Sagas fall into two categories:

Saga Based on Orchestration

A Saga orchestrator manages all transactions in this approach, while the participant services execute local transactions in response to events. You can think of this as the orchestrator’s equivalent of a Saga Manager.

Saga Based on Choreography

There is no central orchestrator in this system. In this approach, during the Saga, each service takes part; they each carry out their transaction and publish events. On those occasions, other services do their things. Depending on the situation, they may or may not publish other events as well.

The Saga Pattern: Advantages and Drawbacks

When using the Saga Pattern, you’ll benefit most from its ability to keep data consistent across services, even if they’re loosely coupled. A microservices architecture must have this feature.

The Saga Pattern‘s main drawback is its apparent complexity when viewed from a programming perspective. Sagas are more difficult for developers to write because of this. Another issue is that in order for sagas to function, compensating transactions must be created.

Sagas, in my opinion, have the potential to assist in the resolution of specific problems and scenarios. If the situation calls for it, these options should be explored or implemented. However, I’m curious if anyone else has used Saga Pattern and how it worked out for them. Are there any frameworks that you used?

And in the end,

Mirbazorgi’s website aims to help you learn and fix your problems by providing articles and practical experiences. Email me if you have any questions.