Got a question: why you says saga orchestration is async can do in concurrently? From what you demoed it looks like orchestrator need to wait for booking service success response then calling payment service again waiting for the payment success or failed response then calling the other. Is this sync or async? It’s sync call to me. Am I understand correctly please let me know if anyone could help me to understand.
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.
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.
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.
A nice channel and I love the way how you are presenting contents. Keep up your hard work and thanks !!!
Thank you for the support 🙏
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.
How have I never seen a video from this channel? Amazing content my friend. Subscribed.
Welcome aboard!
Explanation is giving real time project experience. Thanks a lot
I'm glad you found it relatable!
Best Saga explanation I've ever seen.
Explanation is giving real time project experience and very interesting and informative video.
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
great video, always love your animations and explanations
Great Explaination 🙌
Worth more than lakhs. Thank you.
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.'
Got a question: why you says saga orchestration is async can do in concurrently? From what you demoed it looks like orchestrator need to wait for booking service success response then calling payment service again waiting for the payment success or failed response then calling the other. Is this sync or async? It’s sync call to me. Am I understand correctly please let me know if anyone could help me to understand.
Very good explanation.
Thanks! Keep supporting 😊
Very simple about Saga, thanks
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 ?
Still in Orchestrator SAGA there is single point of failure if orchestrator goes down rite?
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.
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.
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.
@ByteMonk How do you edit/create content ?
Hey ByteMonk, can you please arrange the Microservices Playlist in order where I can understand the topic without shuffling the videos
Thanks much!!
Nice content
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.
You are going to be next Kudvenkat
i can do but actually i dink din din din