🔗Key Takeaways
- 12PC (Two-Phase Commit): coordinator asks all participants to prepare, then commit/abort — blocking if coordinator fails
- 23PC adds a pre-commit phase to reduce blocking, but doesn't solve network partitions
- 3Saga pattern replaces 2PC with a chain of local transactions + compensating actions
- 4In practice, avoid distributed transactions when possible — design for eventual consistency
Atomic Operations Across Services
In a monolith, database transactions are ACID. In microservices, an 'order' spans multiple services (order service, inventory, payment). How do you ensure either all succeed or all rollback? This is the distributed transaction problem.
Phase 1: Prepare
Coordinator sends PREPARE to all participants. Each participant executes the transaction locally, writes to a log, and responds VOTE_COMMIT or VOTE_ABORT.
If ANY participant votes ABORT, the coordinator sends ROLLBACK to all.
Distributed Transaction Approaches
| Approach | Consistency | Availability | Complexity | Use Case |
|---|---|---|---|---|
| 2PC | Strong | Low (blocking) | Medium | Traditional databases (XA) |
| 3PC | Strong | Better than 2PC | High | Theoretical, rarely used |
| Saga (Choreography) | Eventual | High | Medium | Event-driven microservices |
| Saga (Orchestration) | Eventual | High | Medium | Workflow-heavy systems |
| Eventual Consistency | Eventual | Highest | Low | Most microservice systems |
Advantages
- •2PC provides strong consistency across nodes
- •Saga pattern works well for microservices
- •Well-understood failure modes
Disadvantages
- •2PC blocks on coordinator failure
- •Saga compensating transactions are complex to implement
- •Distributed transactions are always slower than local ones
🧪 Test Your Understanding
Knowledge Check1/1
What is 2PC's biggest weakness?