I believe that distributed transaction management is one of the most overlooked complexities when dealing with microservices based architectures. The SAGA pattern is a great way to deal with this complexity. Thanks for sharing this great intro into choreography and orchestration! Would love to see you make a video on Temporal 🙂
Can you explain the difference between a Saga Orchestrator and a Process Manager? Both seem to coordinate messages to and from services and dictate the state of services. I guess it's been one of the more confusing architectural patterns I have had to digest. Choreography makes good sense, but where do we draw the distinction between Saga Orchestrator and Process Manager?
I will try. The Process Manager is one of the patterns described in the Enterprise Integration Patterns book and it applies to its context of messaging with pipes and filters. It's a way to create a controlled sequence in that scenario where the routing logic is centralized, in contrast to the Routing Slip pattern which is decentralized. The Saga Pattern is a higher level pattern that focuses on creating transaction-like guarantees in the context of long-lived transactions using compensation. The two are not mutually exclusive and can be used together. I think you could use a process manager for your saga orchestrator but you also have other options which do not rely on messaging. In conclusion, Process Manager is somewhat lower level than the Saga. That's my understanding.
Correct. Let me explain why I say the saga is an alternative to a distributed transaction. (Either / or) I say alternative because if you can afford doing distributed transactions, there's less value in adopting a Saga pattern. That said the two approaches could coexist but I see it as a rare scenario.
@@MarcoLenzo yes, in my opinion,nowdays xa is not the first consideration in distributed tx for its poor capacity. in jdbc scenario, other solutations like Seata(AT mode) is better.
Do you prefer orchestration or choreography?
I believe that distributed transaction management is one of the most overlooked complexities when dealing with microservices based architectures. The SAGA pattern is a great way to deal with this complexity. Thanks for sharing this great intro into choreography and orchestration! Would love to see you make a video on Temporal 🙂
Thank you for the feedback!
Great info. Thanks for sharing 🙏
Thank you
Great breakdown of SAGA design pattern! Clear explanation on orchestration vs. choreography. Really helpful! Thanks
Glad you found it helpful! 😊
Great, I need to try this tomorrow.
Great! Good luck
Very interesting topic. Nicely and concisely explained. A follow-up would be great. As would overviews of some of the technologies mentioned. Thanks!
Will do! Thank you
I would love to see more on using temporal to orchestrate sagas across multiple bounded contexts!
Coming up soon! Thanks for the feedback!
Great info, thanks for sharing
Thank you!
great thanks
Thank you
Apache Airflow,
AWS Step Function,
Temporal Cloud,
Azure Logic Apps
Yeah and I'm sure there are many more :)
Stop Music in background :(
Yes! I received many complaints and in newer videos I don't use background music. I'm sorry 🙇
Can you explain the difference between a Saga Orchestrator and a Process Manager? Both seem to coordinate messages to and from services and dictate the state of services. I guess it's been one of the more confusing architectural patterns I have had to digest. Choreography makes good sense, but where do we draw the distinction between Saga Orchestrator and Process Manager?
I will try.
The Process Manager is one of the patterns described in the Enterprise Integration Patterns book and it applies to its context of messaging with pipes and filters. It's a way to create a controlled sequence in that scenario where the routing logic is centralized, in contrast to the Routing Slip pattern which is decentralized.
The Saga Pattern is a higher level pattern that focuses on creating transaction-like guarantees in the context of long-lived transactions using compensation.
The two are not mutually exclusive and can be used together. I think you could use a process manager for your saga orchestrator but you also have other options which do not rely on messaging.
In conclusion, Process Manager is somewhat lower level than the Saga.
That's my understanding.
atomikos and bitronix are solutions for XA(2pc) and database need support xa, is not alternative of saga. 🤔
Correct. Let me explain why I say the saga is an alternative to a distributed transaction. (Either / or)
I say alternative because if you can afford doing distributed transactions, there's less value in adopting a Saga pattern.
That said the two approaches could coexist but I see it as a rare scenario.
@@MarcoLenzo yes, in my opinion,nowdays xa is not the first consideration in distributed tx for its poor capacity. in jdbc scenario, other solutations like Seata(AT mode) is better.
@XiaolongLu-j1t Thanks a lot for sharing. I never used Apache Seata. You gave me something new to learn!
orchestration
Thank you for the feedback!