Saga Pattern classification

Well, what happens when a business transaction depends on data that span across multiple microservices. That is where the need for distributed database transactions arises. The saga pattern was first introduced in the 1980s as a solution to solving distributed transactions in a relational database.

Pattern the saga pattern is a design pattern that provides a solution for implementing transactions in the form of sagas that span across two or more microservices a saga can be defined as a sequence of local transactions where each participating micro-service executes one or more local transactions and then publish an event that is used to trigger the next transaction in a saga that resides in another participating microservice.

When one of the transactions in the sequence fails the saga executes a series of compensating transactions to undo the changes that were made by the preceding transactions.

There are two types of sagas 

• Choreography based 
• Orchestration based sagas.

Choreography based:-

Each micros service would publish a domain event after executing a local transaction that would trigger the next transaction in another microserver. So in other words where each service listens to an event from other services, to determine if it should proceed or rollback.

I will use the classic e-commerce use case to explain how the choreography based saga approach works. We could have three microservices and order micro servers payment microservers and shipping microservers.

First, an order microservice creates an order in a pending state and publishes an order that creates that event to the event bus, the payment micros service then license for the order created the event and attempts to process the payment for the order. If it succeeds it publishes a payment process event another microservice the shipping microservers would then listen for the payment process event and attempt to ship the order if it is successful it would publish an order shipped event to the event Pass the order micros service that started the whole process would then listen for the orders shipped event and when it receives it would change the state of the order to approved effectively committing the transaction.

Let's look at how a failure could be handled again in order micros service creates an order in a pending state and publishes an order created event to the event pass the payment micros service would again listen for the order created the event and a team to process the payment for the order. Let's say that the customer has insufficient funds to make the payment. If that is the case the payment micros service can publish an insufficient funds event that the order marker service can listen for.

• Orchestration based sagas.

This time also creates an order saga orchestrator.

The order saga orchestrator then publishes a process payment command event to the event pass the payment service within listening for a process payment command event and a team to process the payment. If it succeeds it would publish a payment process event to the event pass. However this time the order saga orchestrator will consume the payment process event instead of the shipping microservers.

The orders saga orchestrator would then publish a ship order command that the shipping micros service would consume and process if it is successful in its attempts it would reply to the orders saga orchestrator by publishing an order shipped event to the event Press. Finally, the orders saga orchestrator would consume the orders shipped event and update the order as approved.

The orders saga orchestrator could also listen to failure type events. If the payment service publishes an insufficient funds event will the shipping micros service publishers are not shipped event. The order saga orchestrator would handle those events and update the order as reject it. It would also take the responsibility to execute a series of compensating transactions to undo all the changes.