The way to Saga pattern part 2

The Saga design pattern is a way to manage data consistency across microservices in distributed transaction scenarios.

A Saga is a sequence of local transactions.

Each local transaction updates the local database using the familiar ACID transaction frameworks and publishes an event to trigger the next local transaction in the Saga.

?Compensable transactions

If a local transaction fails, then the Saga executes a series of compensating transactions that undo the changes, which were completed by the preceding local?

The SAGA pattern uses a compensating transaction mechanism to handle errors that may occur during the execution of the saga. If an error occurs during one of the local transactions, the compensating transaction is executed to undo the changes made by the previous local transactions. This ensures that the system is left in a consistent state even if a transaction fails.

Consumer point of view

if the user submit a purchase order through the Saga workflow, it might take a moment to see the order finalized. This is because our system uses eventual consistency, meaning each involved service (like inventory and payment) updates independently. The Saga ensures everything goes smoothly in the background, but there might be a short delay before your order reflects the final processed state.

Communication

the communication between the participating services may happen either synchronously, via HTTP or gRPC, or asynchronously, via message brokers or distributed logs such as Apache Kafka.

For the sake of decoupling, communication between microservices should preferably happen asynchronously.