Mastering #microservices: Implement #saga #pattern through #orchestration and #choreography

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)

[santoshgiri]

Wow, you made my day. Explained in very easy and precise. Thank you 😊

[denosingh]

Very Easy Way to describe SAGA Pattern in 8 minutes. Thanks for this video, really very helpful.

[colorful_pages]

Thanks for sharing this video. It's very nice, explained in a very simple and easy language which is very helpful for the learners.

[sonalgupta]

Thanks nicely explained. I had one doubt regarding kafka and other messaging frameworks. as explained in the video messaging is a part of choreography technique but some articles are using kafka for orchestration. So can you please give us some examples of what frameworks or tools can be used for orchestration and choreography respectively in springboot?

[mr.minister]

great video, thanks for explanation. Are there any use cases where both choreography and orchestration are used together? I've seen some complex architectures employing both

[dharmaraosalana]

Nicely explained any disadvantages of Choreagraphy pattern?

[GauravKawatrakir]

is it compulsory to use the command channel and Reply channel between the client and the orchestrator service?

[RadheRadhe-lnsw]

Orchestration is nothing but 2pc or 3pc protocols. If so then what's the point of the Saga pattern?

[devinderkalra]

This is passion,  and I've never seen somebody perform above their capabilities

[GauravKawatrakir]

What is the difference between the orchestrator and the aggregator?

[mrabbas]

6:00 the atomic transactions of different services are coordinated, how?

[morespinach]

The constant sketching is way too distracting. Please just draw things in one go. Tiring to watch.

Question - what tools are used for orchestration or choreography? BPM tools like camunda?

[KeshavDeoSharma]

Sir implementation mt likho title mein, Explanation likho