5 exercises — Learn saga pattern vocabulary: choreography vs orchestration, compensating transactions, and partial failure.
0 / 14 completed
1 / 14
A saga in distributed systems is used to:
Sagas replace distributed transactions (2PC) in microservices. Each saga step is a local transaction; if a step fails, compensating transactions undo the completed steps. The saga maintains business consistency without locking across services.
2 / 14
In a choreography saga, coordination happens because:
Choreography sagas are event-driven: 'OrderPlaced' triggers PaymentService, which emits 'PaymentProcessed', triggering ShippingService, etc. There is no orchestrator — services are decoupled and react to events.
3 / 14
What is a compensating transaction?
Because local transactions are already committed when a later step fails, you can't use database rollback. Instead, a compensating transaction explicitly undoes the business effect — e.g., 'RefundPayment' compensates for 'ChargeCustomer'.
4 / 14
Your team says: "We chose an orchestration saga here to make the flow visible." What is an advantage of orchestration sagas?
Orchestration sagas centralise the flow in a coordinator (often a state machine). This makes the saga's logic visible and traceable — but introduces coupling to the orchestrator and a potential single point of failure.
5 / 14
Fill in the blank: "The payment step succeeded, but the inventory reservation failed, so we need to ___ the payment."
When a later saga step fails, you 'compensate' (undo) the steps that already completed. 'We need to compensate the payment' means executing a 'RefundPayment' compensating transaction.
6 / 14
Reviewer: 'I'm seeing a lot of callbacks here. This saga seems to be constantly pushing events to the next step without any explicit confirmation that it succeeded. It feels… reactive.'
Which term best describes the reviewer's concern regarding this design?
The reviewer is highlighting the potential for 'Callback Hell' within this saga implementation. A callback pattern, especially when deeply nested as in this scenario, can make debugging extremely difficult because each step depends on its predecessor succeeding before it proceeds – a core characteristic of poorly designed asynchronous flows. While Reactive Saga is accurate, 'Callback Hell' more precisely describes the immediate concern expressed regarding the lack of explicit confirmation and the cascading nature of potential failures. Option A is incorrect as eventual consistency is a broader concept not directly related to this specific issue.
7 / 14
Reviewer: 'I'm seeing a lot of callbacks here. This saga seems to be constantly pushing events to the next step without any explicit confirmation that it succeeded. It feels… reactive.'
Which term best describes the reviewer's concern regarding this design?
The reviewer is highlighting the potential for 'Callback Hell' within this saga implementation. A callback pattern, especially when deeply nested as in this scenario, can make debugging extremely difficult because each step depends on its predecessor succeeding before it proceeds – a core characteristic of poorly designed asynchronous flows. While Reactive Saga is accurate, 'Callback Hell' more precisely describes the immediate concern expressed regarding the lack of explicit confirmation and the cascading nature of potential failures. Option A is incorrect as eventual consistency is a broader concept not directly related to this specific issue.
8 / 14
Reviewer: 'I'm seeing a lot of callbacks here. This saga seems to be constantly pushing events to the next step without any explicit confirmation that it succeeded. It feels… reactive.'
Which term best describes the reviewer's concern regarding this design?
The reviewer is highlighting the potential for 'Callback Hell' within this saga implementation. A callback pattern, especially when deeply nested as in this scenario, can make debugging extremely difficult because each step depends on its predecessor succeeding before it proceeds – a core characteristic of poorly designed asynchronous flows. While Reactive Saga is accurate, 'Callback Hell' more precisely describes the immediate concern expressed regarding the lack of explicit confirmation and the cascading nature of potential failures. Option A is incorrect as eventual consistency is a broader concept not directly related to this specific issue.
9 / 14
Reviewer: 'I'm seeing a lot of callbacks here. This saga seems to be constantly pushing events to the next step without any explicit confirmation that it succeeded. It feels… reactive.'
Which term best describes the reviewer's concern regarding this design?
The reviewer is highlighting the potential for 'Callback Hell' within this saga implementation. A callback pattern, especially when deeply nested as in this scenario, can make debugging extremely difficult because each step depends on its predecessor succeeding before it proceeds – a core characteristic of poorly designed asynchronous flows. While Reactive Saga is accurate, 'Callback Hell' more precisely describes the immediate concern expressed regarding the lack of explicit confirmation and the cascading nature of potential failures. Option A is incorrect as eventual consistency is a broader concept not directly related to this specific issue.
10 / 14
During a code review for an e-commerce saga processing orders, a developer notes: 'The service is emitting events every time the inventory check succeeds. It seems overly verbose and potentially introduces coupling if the inventory service changes its event format.' Which of the following best describes this situation?
// Event emitted when inventory check succeeds
emit('inventoryCheckSucceeded', {itemId: item.id});
The scenario describes loose coupling, a core benefit of the Saga pattern. Events allow services to react independently without direct dependencies. Tight coupling would indicate a problem with synchronous communication or shared state. Event Storming is a design process, not a pattern itself, and choreography focuses on event publication rather than explicit orchestration.
11 / 14
Slack message from Sarah (Backend Engineer) to Mark (Frontend Developer): 'Just deployed the new order saga. It's heavily reliant on asynchronous event handling, so changes in the backend won't immediately break the frontend. We're using a choreography approach with compensating transactions for failures.' What does 'compensating transaction' refer to in this context?
// Example compensating transaction (simplified)
if(paymentFailed) {cancelOrder();}
'Compensating transactions' are crucial for ensuring data consistency in Sagas. They are specifically designed to reverse the steps taken by a primary transaction when an error occurs – unlike standard transactional rollback which only applies to committed changes. The scenario highlights asynchronous handling and event-driven rollback.
12 / 14
A developer is writing a PR description for a new Saga implementation. They want to clearly communicate the design choices. Which sentence best describes the benefit of using an orchestration saga over a choreography saga?
// Orchestration Saga (simplified)
orchestrator.nextStep(event);
Orchestration sagas provide a centralized control point. This makes it much easier to track the progress of the saga and understand the flow of events – crucial for debugging and maintaining complex distributed systems. Choreography focuses on loose coupling but can make troubleshooting more difficult.
13 / 14
During a standup meeting, David (Lead Developer) says: 'We're using an orchestration saga to manage this multi-step order processing flow. We have a central orchestrator that calls the next service based on each event.' What is the primary advantage of this approach?
// Orchestrator logic
orchestrator.nextStep(event);
The key advantage of an orchestration saga is the centralized control it offers. This enables the team to maintain data consistency – vital for e-commerce systems – by managing the sequence of operations and ensuring that each step completes successfully before moving on to the next. Asynchronous communication reduces latency.
14 / 14
A developer is reviewing a Saga implementation and sees this code: 'If the inventory reservation fails after a successful payment, we need to roll back the payment.'. What design pattern element is being demonstrated?
// Compensating transaction logic
rollbackPayment();
This scenario directly illustrates the concept of a compensating transaction. This is a critical element in Sagas, ensuring that failures are handled gracefully and data integrity is maintained by reversing operations when necessary. The other options represent different concepts within distributed systems design.
What does the "Saga Pattern — Vocabulary — Event-Driven Architecture | CoderLingo" exercise cover?
Learn saga pattern vocabulary: choreography vs orchestration, compensating transactions, and partial failure.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Saga Pattern — Vocabulary — Event-Driven Architecture | CoderLingo"?
This exercise has 14 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Event-Driven Architecture Language exercises?
Browse the full Event-Driven Architecture Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.