Art of Managing microservice using different strategies.

Nowadays developers are moving towards microservice-based architecture, instead of following Monolithic-based architecture.

We have various benefits of using a microservice-based architecture as in microservice every service is responsible for the type of work they plan.

Once we have successfully developed the code for each of our microservice, they need to communicate amongst themselves.

Also with microservice since we have a different service for handling the transaction, it becomes difficult at times if in case any service responds unexpectedly.

Example

A user has come to your website to purchase a book. The user does everything right, but unfortunately your service fail and user is shown “something needs to be fixed”.
We need to have some mechanism to mitigate that. There should be some way or another which should help user with end to end experience.

Saga Pattern: Saga pattern is where each action is a local transaction. Once that transaction is updated it triggers a database update. Once the database update is successful it initiates the next local transaction. Each local transaction has performed some action.

Now what if any local transaction fails, the saga pattern is responsible for undoing every transaction by triggering a series of compensation transactions which does the hard work. It helps undo the entire transaction, returning it to the last stable state.

Saga Microservices has two ways by which they coordinate amongst themselves.

1. Microservice orchestration.

2. Microservice choreography.

You can read more about microservices orchestration and microservices choreography in this article. Microservices Orchestration vs Choreography | (Technology)

Why Microservices are required?

About Microservice we have already tried to understand. Having individual services is based upon the requirement. We have the opportunity to easily scale in and scale out the service.

The individual services are standalone and tend to perform as single set related actions. For example, if we have an order microservice. We can assume this service will be performing all the actions related to order management.

We don't need to worry about the other services, as the service owner can work on scaling the service at the individual level. We can choose our technology stack for that service based on the requirement of the service

Benefits of Saga Architecture Patterns

If one uses saga architecture patterns while designing the architecture, it ensures that either all the transactions will be either fulfilled successfully. If the transaction is unable to commit successfully, a compensatory transaction will be triggered to undo the work.

We have both ways of implementing the Saga pattern, either using microservice orchestration or microservice choreography. At the end of your entire design of the architecture, the final goal will always be to either commit to a transaction in its entirety.

In any case, if a transaction is stored in an incorrect state, i.e. partial information is maintained, and the compensation transaction is not triggered properly that would be an incorrect implementation of the entire process.

Points to Be Notes In Saga Design Pattern.

Transaction

Transaction as the name suggests is any action performed in the Saga design pattern. Its goal is to perform any action completely and launch a compensation transaction in case anything fails

Compensable Transaction

A compensable Transaction can be considered as any transaction which is triggered to bring the state into the back stable stage. The compensable transaction is triggered when any issue occurs in normal transactions.

Retrybale Transaction

Retryable transactions are that transaction which is triggered post-pivot transactions are guaranteed to succeed. The pivot transaction is those which if committed, are neither Retryable nor compensable.

When to User Saga Pattern?

We can use the saga pattern if our application support one of the following case. If our application is loosely coupled and the different transactions can be performed individually.

Secondly, if in any particular case, we need to require to roll back the series of transactions in the case of the distributed system. The saga pattern helps you roll back the state to the last stable stage in case of system errors.

Final Thoughts.

Now to wrap up, we understood about saga pattern. The goal of adopting the Saga pattern is to achieve a state in your application which is either completely fulfilled or reverted accordingly.

If you have implemented the Saga pattern properly, chances are rare that your application is committed in a partial state.