Distributed Transactions

Challenges in Distributed Systems

• Moving from monolithic, single-process systems to distributed microservices complicates transactional integrity.
• Traditional database transactions (begin, commit, rollback) are straightforward when dealing with one service and database, but not across multiple independent services.
• Ensuring consistency becomes more difficult as each microservice typically owns its own data.

Two-Phase Commit Protocol

• Introduced as a basic solution for coordinating transactions across services.
• Explained using Alice and Bob: involves a preparatory phase (are you ready?), followed by a commit/cancel phase.
• If any participant says “no” at any phase, previous actions can be undone to maintain consistency.
• Example: In e-commerce, inventory and payment services use two-phase commit to stepwise ensure inventory is reserved and payment is processed, with rollback if any step fails.
• Downsides include blocking behavior (all services must wait for one another), performance bottlenecks, risks of single point of failure in the coordinator, and rigid binary outcomes (commit or abort only).

Saga Pattern for Distributed Transactions

• Presented as an alternative to two-phase commit for distributed systems.
• Uses a sequence of local transactions, each with a potential compensating transaction to undo previous work if a failure occurs.
• Illustrated with Alice and Bob organizing a party: if a step fails (e.g., booking food), prior steps (like venue booking) can be undone.
• Applied to e-commerce: order saga starts with reserving inventory, proceeds to payment, and possibly to delivery scheduling. Failures at any stage trigger compensating actions (e.g., refund inventory if payment fails).
• Offers flexibility, allowing partial commits and nuanced compensation logic, unlike two-phase commit’s rigid approach.

Trade-Offs and Considerations

• Implementing saga is more complex, requiring thorough coordination and design, especially for handling both success and failure scenarios.
• Saga coordinator can still be a single point of failure.
• Step order matters: in e-commerce, taking payment last is practical because undoing logistics is easier than refunding money.
• Determining ownership of the saga (which service manages it) is a design consideration; may use an event-driven approach where order services publish events and others react.
• Distributed transactions are inherently complex; most business processes require cross-service coordination, so understanding these trade-offs is critical.