Hi, I have a doubt in SAGA. Consider service1 and service2. When service1 passes, service2 will be initiated. When the service2 is failed, and if the service1's value is changed in the meantime, what will happen? Will it lead to data inconsistency? Correct me if I am wrong.
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.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
Best Saga explanation I've ever seen.
An underrated channel. Keep going and it's definitely gonna be a popular channel
Very interesting and informative video. Please keep sharing such videos where a non technical people can understand it.
Explanation is giving real time project experience. Thanks a lot
I'm glad you found it relatable!
Explanation is giving real time project experience and very interesting and informative video.
Very good explanation.
How have I never seen a video from this channel? Amazing content my friend. Subscribed.
Welcome aboard!
You deserve more views.. this is gold..
Thanks you so much 😊.
Definitely One of the best videos I have seen ... Respect for your work .. Please create more videos on Microservices
Worth more than lakhs. Thank you.
great video, always love your animations and explanations
Great Explaination 🙌
Very simple about Saga, thanks
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.'
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 ?
Hi, I have a doubt in SAGA. Consider service1 and service2. When service1 passes, service2 will be initiated. When the service2 is failed, and if the service1's value is changed in the meantime, what will happen? Will it lead to data inconsistency? Correct me if I am wrong.
Still in Orchestrator SAGA there is single point of failure if orchestrator goes down rite?
Hey ByteMonk, can you please arrange the Microservices Playlist in order where I can understand the topic without shuffling the videos
@ByteMonk How do you edit/create content ?
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.
Thanks much!!
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 content
You are going to be next Kudvenkat
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.
i can do but actually i dink din din din