Distributed Systems
Sagas: multiple-choice review
Crux Multiple-choice synthesis across the sagas unit — 2PC's failure mode, compensation vs rollback, choreography vs orchestration, and the anomalies that follow from losing isolation.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a design call you make when one transaction cannot span the work — not a definition to recite, but a tradeoff to weigh when partial failure is the normal case.
Goal
Confirm you can connect why 2PC fails across services, why a compensation is not a rollback, when choreography beats orchestration, and which anomalies fall out of losing isolation — the synthesis the lesson built toward.
Quiz
Completed
A checkout path crosses six services, one of them a third-party payment gateway. Why is wrapping them in one two-phase commit the wrong move?
Heads-up Round-trip count is not the issue — the held locks and the blocking coordinator are. Even if 2PC were fast, locking a gateway you do not own for the duration is impossible.
Heads-up 2PC handles any number of participants; the protocol is correct. The problem is operational — cross-service locks and a single blocking coordinator — not correctness.
Heads-up Even a perfectly available coordinator still forces participants to hold locks across the network round trip, and a third-party gateway cannot vote in your prepare phase. HA fixes neither.
Quiz
Completed
Step T2 charges the card; step T3 fails, so the saga runs C2. What does C2 actually do, and why does the distinction matter?
Heads-up There is nothing to roll back — T2 committed locally and durably the instant it ran. A compensation is a brand-new business action, not a database rollback.
Heads-up A saga exists precisely because there is no coordinator holding a transaction open. Each step commits immediately; the only undo is an explicit compensation you write.
Heads-up It cannot be rolled back, but it can be compensated. Skipping C2 leaves money taken with no order — the inconsistency a saga's compensations exist to prevent.
Quiz
Completed
A trip saga does T1 book flight, T2 book hotel, T3 rent car, then charge the card, then email a confirmation. Why does a senior order it this way?
Heads-up Charging first means every later failure forces a refund — the money moved twice and a fee may stick. Do the cancellable, reservable work first; charge only once the rest succeeded.
Heads-up Not every step does — a sent email cannot be unsent, and a refund is not a clean inverse of a charge. Step ordering is exactly how you minimise reliance on imperfect or missing compensations.
Heads-up Deployment order is irrelevant. Saga step order is a design choice driven by reversibility — put the steps with the worst compensations last.
Quiz
Completed
A 6-step order flow spans 5 services with retries, timeouts, and a manual-approval step that can wait days. Choreography or orchestration?
Heads-up No single point of failure is real, but at 6 steps over 5 services the logic is scattered nowhere-and-everywhere, and a multi-day wait needs persisted state no event-reacting service owns. Tracing a stuck saga becomes archaeology.
Heads-up That cost is real but worth paying once the flow has branches, retries, timeouts, and a multi-day wait — exactly the complexity where 'where is the logic?' stops having a one-file answer.
Heads-up The choice is a multi-quarter commitment. Choreography fits short, stable, linear flows; this flow's branches, retries, and multi-day wait push hard toward orchestration.
Quiz
Completed
Saga B reads an order that saga A has committed but will later compensate away, and acts on it. Which anomaly is this, and why is it even possible?
Heads-up Sagas hold no locks across steps, so classic deadlock is not the issue. The opposite is true — nothing is locked, so not-yet-final state is freely visible. That is a dirty read.
Heads-up Non-repeatable read is one saga reading the same value twice and getting different results. Reading another saga's about-to-be-compensated state is a dirty read.
Heads-up Committed locally is not the same as the saga succeeding. A step can commit and still be compensated away, so reading it can mean acting on data that vanishes — a dirty read.
Quiz
Completed
Two sagas concurrently adjust the same account balance and one overwrites the other's change. Which countermeasure removes this lost update most directly?
Heads-up Backoff lowers the odds, it does not remove the race. Under load the writes still interleave and one still clobbers the other; the fix is an order-independent or version-checked update.
Heads-up Reintroducing 2PC defeats the entire reason for the saga and reinstates cross-service locks. The lost update is fixed at the application level with commutative updates or an optimistic version check.
Heads-up Each step is a separate local transaction in a separate service; no single database isolation level spans the saga. Isolation here is reconstructed in the application — commutative updates, semantic locks, version checks.
Recap
The through-line: a single ACID transaction cannot span services, and 2PC’s cure — cross-service locks plus a blocking coordinator — is worse than the disease. A saga gives up the global transaction for local commits plus hand-written compensations, which are new forward actions, not rollbacks, so you order irreversible steps last. You wire steps with choreography (decentralized but scattered) or orchestration (one durable place to read and resume), and you pay for losing isolation with application-level defences — semantic locks, commutative updates, and version checks — against dirty reads and lost updates.