Distributed Transaction Lab (Interactive)
Step an Order-Inventory-Payment transaction through 2PC, Saga, or TCC and break it mid-flight to see who recovers. Execute each protocol step by step: 2PC blocks on locks, Saga compensates with reverse actions, TCC reserves then confirms. Inject an inventory failure and compare lock-hold time.
2PC vs Saga vs TCC Step Arena
Checkout touches three private databases. Choose a coordination protocol, break step 3, and step through what each one pays.
How It Works Under the Hood
Cross-service atomicity has three answers with three failure profiles. Two-phase commit keeps everyone blocked on the coordinator — strong consistency that dies if the coordinator crashes after prepare, and lock-hold time spans every participant. Saga orchestration drops locks entirely: each step commits locally and failures fire compensating events, trading isolation for availability with interim states like money debited but inventory not yet reserved. TCC splits into Try/Confirm/Cancel reserving resources so the visible state is always consistent, but every service must implement three endpoints and its own reservation expiry.
Core Architectural Principles
- Step runner advances one protocol action at a time, showing locks, prepares, commits, or compensations live.
- Fault injection fails Inventory mid-transaction: 2PC rolls back locked, Saga compensates, TCC cancels the Try.
- Coordinator-crash mode exposes 2PC's blocking ambiguity versus log-replay recovery in Sagas.
For checkout across services, default to an orchestrated saga and justify it: no multi-service lock hold, deterministic compensation, audit trail in the orchestrator. Say why not 2PC — XA across microservices couples availability and most brokers and NoSQL stores lack it. Mention TCC when you need reservation semantics like holding inventory, and own its cost: three endpoints per operation.
2PC buys atomicity with blocking locks; Sagas and TCC buy availability and throughput with compensation complexity.