Questions: Saga Pattern for Long-Running Distributed Transactions

Question 1

A travel booking saga completes hotel and flight reservations, but the car rental step fails. What does the saga do to recover?

• A. It issues a global rollback, atomically reverting all committed transactions as 2PC would
• B. It executes compensating transactions in reverse order — cancelling the flight, then cancelling the hotel — to semantically undo the completed steps
• C. It retries the car rental step indefinitely until the service recovers
• D. It marks all steps as 'pending' and holds locks until the car rental service responds

Answer: (B)

The hotel and flight reservations have already committed locally — they are durable. There is no global rollback in a saga. Instead, each step has a compensating transaction (a new forward action that reverses the business effect), and they run in reverse order. The saga achieves eventual consistency through compensation, not atomicity. This is the fundamental tradeoff: sagas avoid the blocking and coordinator-crash problems of 2PC by accepting that intermediate states are visible and recoverable only through compensations.

Question 2

Why must every step in a saga — both the forward transactions and the compensating transactions — be designed to be idempotent?

• A. To satisfy the ACID atomicity requirement that all-or-nothing execution imposes
• B. Because network failures can cause a message to be delivered and processed more than once; idempotence guarantees the same outcome whether a step runs once or multiple times
• C. To allow the saga coordinator to parallelize steps safely
• D. Because distributed systems cannot guarantee message ordering, making duplicates inevitable during normal operation

Answer: (B)

In distributed systems, at-most-once delivery is difficult to guarantee. A network timeout may cause a retry even though the original message was processed. A compensating transaction that runs twice must produce the same result — a 'cancel hotel' that double-refunds or throws an error on second execution breaks the recovery guarantee. Idempotence is the property that makes retries safe, which in turn makes the saga resilient to the partial failures and message duplicates that are normal in distributed environments.

Question 3

Sagas provide the same atomicity guarantees as two-phase commit — nearly every step either most commits or most aborts — but without blocking on global locks.

• T. True
• F. False

Answer: False

Sagas provide eventual consistency, not ACID atomicity. The critical difference is that intermediate states ARE visible: other transactions can see and act on a hotel reservation before the flight is confirmed. In 2PC, the global lock prevents any other transaction from observing partial state. A saga's compensating transactions can reverse the business effect, but they cannot retroactively prevent other transactions from having observed and acted on the intermediate state. This is a fundamental tradeoff, not a free improvement over 2PC.

Question 4

In a saga, compensating transactions semantically reverse completed steps but are not true database rollbacks, because the original local transactions have already committed and made their changes durable.

• T. True
• F. False

Answer: True

This is the defining characteristic of saga compensations. When the hotel reservation commits locally, it is immediately durable — visible in the hotel's database, potentially seen by other systems. The compensation 'cancel hotel' is a new forward-moving transaction that creates a cancellation record. It cannot erase the fact that the reservation existed, and it cannot undo any side effects that other systems may have already acted upon. This is why compensation design is an application-level responsibility requiring careful business logic, not a database-level guarantee.

Question 5

What is the fundamental difference between a saga's compensating transaction and a traditional 2PC abort/rollback, and why does this distinction matter for application design?

Model answer: A 2PC rollback is a database-level operation that atomically reverts uncommitted changes before they become visible to anyone. A saga compensation is a new, independent business transaction that reverses the *effect* of an already-committed step — but that step's changes are already durable and may already have been observed by other systems. This matters because compensations must be explicitly designed, coded, and made idempotent by the application developer. They also may fail (a hotel that has already been re-booked cannot be cancelled), potentially requiring manual intervention. 2PC's atomicity is transparent to the application; saga compensations are not.

This distinction drives all the extra engineering complexity sagas require. 2PC atomicity is 'automatic' at the database level — the developer declares a transaction boundary and the system handles failure. Saga compensations must be written explicitly, made idempotent, and tested for every failure scenario. The payoff is that sagas work across independent services and long timeframes where 2PC's locking would cause cascading failures or indefinite blocking.