Orchestration based Saga looks very similar to 2-phase-commit. It would be great if you compare both of them in your future newsletter. Thanks Saurabh!!!
SAGAs are like a safety net for distributed systems.
I mostly prefer the orchestrator approach because it provides a central control point, making it easier to manage the transaction's flow and handle errors.
The trade-off is that it can become an SPF, so it has to be resilient enough or incorporate a buffer mechanism like a queue.
Based on this, I think most of us used the Saga pattern without knowing it.
For example, checking out a digital product with Stripe Checkout:
1. The user clicks a button and gets redirected to the stripe payment page
2. they enter card details and click buy
3. stripe verifies the details and processes the transaction
4. when this processing ends, it calls a webhook
5. inside the webhook, you email your digital product to a buyer
Would this be a Saga pattern?
Another thing that came to my mind is the software I worked on as a Junior engineer. It was a BPM-based orchestration tool where users could draw a flowchart of actions, and the engine would execute it. One of the customers was a big printing center, and it worked like this:
1. a telecommunications company uploaded PDFs through the app UI to this printing center
2. the app moved the PDFs to a machine that has access to a giant printer
3. sent the command to print the PDFs
4. when the printing has finished, the app emails the telco company about the status
Is this a Saga pattern as well?
Does the orchestrator have to be external (like the engine I was working on), or can it be part of your application logic?
One thing that usually defines a Saga is the existence of compensating transactions. Like if any step fails, do you need to rollback the steps done previously? I think the Stripe checkout thing is more of a workflow where you can stop at any point. Failure to send an email might not be something for which you need to reverse the transaction.
The telecom case sounds a little more grey to me. For example, if moving the PDFs to the machine fails, do we need to revoke the upload step and ask the users to re-upload if they want to print again? If yes, it could be looked at as a Saga in my view.
The orchestrator can be part of the application logic. In a few cases I have worked on, it was actually one of the services within the application.
I love this pattern, it solves the problem efficiently, awesome newsletter post my friend!
Thanks for the great feedback Daniel
Orchestration based Saga looks very similar to 2-phase-commit. It would be great if you compare both of them in your future newsletter. Thanks Saurabh!!!
Sure Ashwani. Thanks for the suggestion👍
SAGAs are like a safety net for distributed systems.
I mostly prefer the orchestrator approach because it provides a central control point, making it easier to manage the transaction's flow and handle errors.
The trade-off is that it can become an SPF, so it has to be resilient enough or incorporate a buffer mechanism like a queue.
Great article; thanks for the mention, Saurabh!
Thanks for the great points Raul.
I've also found orchestration-approach being preferred most of the times, including in a few of the projects I was part of.
Based on this, I think most of us used the Saga pattern without knowing it.
For example, checking out a digital product with Stripe Checkout:
1. The user clicks a button and gets redirected to the stripe payment page
2. they enter card details and click buy
3. stripe verifies the details and processes the transaction
4. when this processing ends, it calls a webhook
5. inside the webhook, you email your digital product to a buyer
Would this be a Saga pattern?
Another thing that came to my mind is the software I worked on as a Junior engineer. It was a BPM-based orchestration tool where users could draw a flowchart of actions, and the engine would execute it. One of the customers was a big printing center, and it worked like this:
1. a telecommunications company uploaded PDFs through the app UI to this printing center
2. the app moved the PDFs to a machine that has access to a giant printer
3. sent the command to print the PDFs
4. when the printing has finished, the app emails the telco company about the status
Is this a Saga pattern as well?
Does the orchestrator have to be external (like the engine I was working on), or can it be part of your application logic?
Thanks for the shoutout, Saurabh!
You make some interesting points Akos.
One thing that usually defines a Saga is the existence of compensating transactions. Like if any step fails, do you need to rollback the steps done previously? I think the Stripe checkout thing is more of a workflow where you can stop at any point. Failure to send an email might not be something for which you need to reverse the transaction.
The telecom case sounds a little more grey to me. For example, if moving the PDFs to the machine fails, do we need to revoke the upload step and ask the users to re-upload if they want to print again? If yes, it could be looked at as a Saga in my view.
The orchestrator can be part of the application logic. In a few cases I have worked on, it was actually one of the services within the application.
Curious with the orchestrator based saga will we not create a single point of failure? Plus with time the orchestrator service will become huge.
Yes pratik, those are valid concerns about the orchestration pattern and one of the main cons of not going for it if possible.
Very nicely explained !!
Thank you
Nicely explained with most common scenario.
Thank you!