Mastering

Introduction to Saga Pattern
#sagapatternmicroservices, #sagamicroservices, #sagadesignpatternmicroservices, #microservicessagapattern, #sagapatternspring-boot, #patternsaga, #microservicessaga,
#sagadistributedtransaction, #sagapatternjava, #sagadesignpatterninmicroservices, #sagainmicroservices, #sagaorchestrator, #microservicetransactionpatterns, #sagapattern,
#sagapatterninmicroservices
A Saga Pattern is a sequence of local transactions where each transaction updates data within a single service. The first transaction in a saga is initiated by an external request corresponding to the system operation, and then each subsequent step is triggered by the completion of the previous one.

There are a couple of different ways to implement a saga transaction, but the two most popular are:

Events/Choreography: When there is no central coordination, each service produces and listens to other service’s events and decides if an action should be taken or not.

Command/Orchestration: when a coordinator service is responsible for centralizing the saga’s decision making and sequencing business logic.

Let’s go a little bit deeper in each implementation to understand how sagas work.

In the Events/Choreography approach, the first service executes a transaction and then publishes an event. This event is listened by one or more services which execute local transactions and publish (or not) new events.

The distributed transaction ends when the last service executes its local transaction and does not publish any events or the event published is not heard by any of the saga’s participants.

Rolling back a distributed transaction does not come for free. Normally you have to implement another compensating transaction for what has been done before.

Events/Choreography is a natural way to implement a Saga orchestration pattern. It is simple, easy to understand, does not require much effort to build, and all participants are loosely coupled as they don’t have direct knowledge of each other. If your transaction involves 2 to 4 steps, it might be a very good fit.

However, this approach can rapidly become confusing if you keep adding extra steps in your transaction as it is difficult to track which services listen to which events. Moreover, it also might add a cyclic dependency between services as they have to subscribe to one another’s events.

Finally, testing would be tricky to implement using this design, in order to simulate the transaction pattern you should have all services running.

The Saga design pattern is a way to manage data consistency across microservices in distributed transaction scenarios. A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step. If a step fails, the saga executes compensating transactions that counteract the preceding transactions.

The Saga pattern provides transaction management using a sequence of local transactions. A local transaction is the atomic work effort performed by a saga participant. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails, the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.

In Saga patterns:

Compensable transactions are transactions that can potentially be reversed by processing another transaction with the opposite effect.
A pivot transaction is the go/no-go point in a saga. If the pivot transaction commits, the saga runs until completion. A pivot transaction can be a transaction that is neither compensable nor retryable, or it can be the last compensable transaction or the first retryable transaction in the saga.
Retryable transactions are transactions that follow the pivot transaction and are guaranteed to succeed.
There are two common saga implementation approaches, choreography and orchestration. Each approach has its own set of challenges and technologies to coordinate the workflow.

Choreography
Choreography is a way to coordinate sagas where participants exchange events without a centralized point of control. With choreography, each local transaction publishes domain events that trigger local transactions in other services.

Orchestration
Orchestration is a way to coordinate sagas where a centralized controller tells the saga participants what local transactions to execute. The saga orchestrator handles all the transactions and tells the participants which operation to perform based on events. The orchestrator executes saga requests, stores and interprets the states of each task, and handles failure recovery with compensating transactions.

Welcome: (0:00)
Monolith V/S Microservice: (0:08)
Why Saga Required: (1:24)
What is Saga Pattern: (2:18)
Coordination Techniques in Saga: (2:45)
Orchestration Mode: (2:58)
Choreography: (5:08)
Thank You: (7:52)