Microservices Transactions Using Saga Pattern

_{photo created by rawpixel.com – www.freepik.com}

Transaction is essential to maintain data consistency in the application. In microservices architecture, applications are divided into multiple independent services. Each services have its own database, that is data is private to each service. Saga pattern is solution to maintain the data consistency across application. 

What is Saga Pattern? 

Saga pattern help us in creating loosely coupled services and maintaining data consistency across application. Saga in sequence of local transactions. Each service in a Saga performs its own transaction and publish an event for next service. The other service listens to the event and perform the next local transaction. If a transaction failed in anyone of the services, then the series of compensating transactions is executed to undo impact of preceding transactions. 

Understanding Saga pattern with an example 

In this example, we are considering a minimal application flow of customer making an order on ecommerce site.  

Distributed Transaction ( Two-Phase Commit ) 

In distributed transactions, a transaction spans the databases. Hence, services updates are not atomic and services are not loosely coupled. 

 The sequence of transaction getting executed for an order in 2 phase commits are  

1. createOrder() 

2. payment() 

If payment() will get failed then the transaction createOrder() will also be rollbacked. 

Saga 

In Saga pattern, services transactions are local transaction. It doesn’t span to multiple databases. 

1. createOrder()  

createOrder() will execute a transaction to create order in then pending state and publish an event for payment service to execute the payment  

2. payment() 

Payment service will listen to the event and execute payment(). Upon payment() execution it publishes event for order service to execute next local transaction 

3. approveOrder() 

Order service listen to event publish by payment service, if event correspond to successful it execute approveorder() to approve the order. 

4. rejectOrder() (Compensating Transaction) 

Order service listen to event publish by payment service, if event correspond to successful it execute rejectOrder() to reject the order() 

Types of Sagas 

There are two types of Sagas 

1. Orchestration-based Saga 

There is coordinator service responsible of Saga decision making and sequencing the business logic. The coordinator service generally refers as “Saga Manager”. Saga manager publish the events/message for other service to execute the next local transaction based on the event/message publish from preceding local transaction in the Saga. 

2. Choreography-based Saga 

There is no central coordinator each service listens to the event/message publish by other services. Based on the event/message it executes the local transaction and publish the next event/message. 

Conclusion 

Saga pattern help us in maintaining the data consistency across whole application. Services execute atomic database update. Unlike, two-phase commits where a transaction spans the databases. The only disadvantage of Saga pattern is the complex programming model where a developer must design the compensating transactions.  

In the next blog, we will look understand the Orchestration-based saga and Choreography-based saga in more detail. 

Thanks