Saga Pattern | Distributed Transactions | Microservices

[@krzysztof9711]

An underrated channel. Keep going and it's definitely gonna be a popular channel

[@nuthankamera5651]

Very interesting and informative video. Please keep sharing such videos where a non technical people can understand it.

[@ronaksiddhpura07]

Explanation is giving real time project experience and very interesting and informative video.

[@sathishd273]

Explanation is giving real time project experience. Thanks a lot

[@ByteMonk]

I'm glad you found it relatable!

[@pedromiotti3033]

How have I never seen a video from this channel? Amazing content my friend. Subscribed.

[@ByteMonk]

Welcome aboard!

[@umangsomtiya5826]

Great Explaination 🙌

[@Zmey5656]

Very simple about Saga, thanks

[@ujjwalaggarwal7065]

great video, always love your animations and explanations

[@KrishDholeria]

as you said we can use zookeeper to implement 2 phase commit. Similarly, is there any framework which can be used to implement orchestrated saga?

[@Vikaskumar-hb8uo]

step functions is such an aws service.'

[@sscapture]

Thanks much!!

[@java-aws-techie]

Great video. Might help if you could also discuss about some tools or frameworks to implement saga.

[@vivek.tiwary]

You can use Azure durable function to implement an orchestrator saga. For choreography, you can use Azure Sb.

[@java-aws-techie]

So Aws step functions as orchestrator and SQS for choreography. Clear. Thanks.

[@ByteMonk]

Thank you for suggestions and replies, will cover them up in my upcoming videos. I try to keep my videos under 10 mins, but this one turned out to become too long because of the context I had to provide in the beginning.

[@arvindpurohit2722]

Nice content

[@sathishd273]

You are going to be next Kudvenkat

[@liangtianzhang513]

how is an orchestrated saga async if it makes serial requests and requests depend on each other? Isn't it the same as a central coordinator ?

[@zummotv1013]

can we have multiple instances of a Saga orchestrator to ensure high availability, scalability, and fault tolerance, by ensuring that only one orchestrator instance handles a particular Saga at any given time.

[@ByteMonk]

Yes, it is possible to have multiple instances of a Saga orchestrator to achieve high availability, scalability, and fault tolerance. The key to making this work effectively is to ensure that only one orchestrator instance is responsible for a particular Saga at any given time. This can be achieved through various mechanisms, you can use a distributed locking mechanism (like Zookeeper, Redis, or a database-based lock) to ensure that only one orchestrator instance can handle a particular Saga at any given time. This prevents multiple instances from concurrently processing the same Saga, or you can also Implement a leader election algorithm to designate one orchestrator instance as the active leader responsible for managing Sagas. I have made videos on each of these topics, which you can checkout in my System Design playlist.

[@yravi37]

@ByteMonk How do you edit/create content ?

[@pravee150]

Still in Orchestrator SAGA there is single point of failure if orchestrator goes down rite?

[@pradeepbisht3397]

Nice video ! can you share article you talking about in video?

[@ByteMonk]

Thank you. This is from my experience, I did not made it into an article, but will consider in future.

[@vaibhavnitnaware5829]

[@metaltoad8462]

i can do but actually i dink din din din