Microservice Patterns - 4.1 Managing transactions with sagas - Transaction management in a microservice architecture

Reference

https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson/dp/1617294543

Challenges

In a monolithic system, a createOrder operation only need to rely on a relational database with transactional annotation.

In a microservice system, a createOreder operation need make sure operations in Kitchen Service, Customer Service, Order Service, Accounting Service all success. Because each service has its own database.

Traditional Approach

Simply to say: two-phase commit. Ex. Java EE can complete multiple service transaction by JTA.

Problem

1. Modern technology such as No-SQL database or Message broker such as Kafka doesn't support it.
2. Traditional approach is synchronous operation with lower availability (all services must be available)
   2 Services with 99.5% aviliability, overall availability become 99%

Using the Saga pattern to maintain data consistency

Saga: Maintain data consistency across services using a sequence of local transactions that are coordinated using asynchronous messaging. See http://microservices.io/ patterns/data/saga.html.

Each local transaction updates data within a single service using the familiar ACID transaction frameworks and libraries mentioned earlier

1. System operation init the first step of Saga
2. Completion of local transaction triggers the execution of next local transaction
3. a saga must be rolled back using compensating transactions

Example: Create Order Saga

1. Init by external createOrder request
2. Other five transactions are triggered after previous done

Challenges

1. Lack of isolations between Sagas
2. Rollback when error occurs

SAGAS USE COMPENSATING TRANSACTIONS TO ROLL BACK CHANGES

When a step fail, previous sagas need undo changes (must be undone)