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.
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.
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.
Explanation is giving real time project experience and very interesting and informative video.
Very interesting and informative video. Please keep sharing such videos where a non technical people can understand it.
An underrated channel. Keep going and it's definitely gonna be a popular channel
Explanation is giving real time project experience. Thanks a lot
I'm glad you found it relatable!
How have I never seen a video from this channel? Amazing content my friend. Subscribed.
Welcome aboard!
Very simple about Saga, thanks
Great Explaination 🙌
great video, always love your animations and explanations
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?
step functions is such an aws service.'
@ByteMonk How do you edit/create content ?
You are going to be next Kudvenkat
Great video. Might help if you could also discuss about some tools or frameworks to implement saga.
You can use Azure durable function to implement an orchestrator saga. For choreography, you can use Azure Sb.
So Aws step functions as orchestrator and SQS for choreography. Clear. Thanks.
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.
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 ?
Thanks much!!
Nice content
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.
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.
Nice video ! can you share article you talking about in video?
Thank you. This is from my experience, I did not made it into an article, but will consider in future.