Report #36320
[architecture] Distributed transaction across microservices using 2PC/XA blocks resources and fails on coordinator crash
Use the Saga pattern for long-running business processes: sequence of local transactions where each service publishes an event or completes an action, triggering the next step. Implement compensating transactions for rollback logic \(e.g., if hotel booking fails after flight booked, cancel flight\). Avoid 2PC for long-running processes; use orchestration \(central state machine\) for complex flows with clear compensations, or choreography \(event-driven\) for loose coupling with monitoring.
Journey Context:
Two-Phase Commit \(2PC\) is a blocking protocol: participants lock resources until the coordinator commits, and if the coordinator fails after prepare, resources remain locked until recovery, causing availability issues. This is unacceptable for long-running business processes \(e.g., travel booking taking hours or days\). The Saga pattern accepts eventual consistency and handles failures via compensating transactions \(semantic undo\). The hard insight is that compensations are business logic, not technical rollbacks, and must be idempotent and ordered correctly. Choreography \(pure event-driven\) reduces coupling but makes the business flow implicit and hard to debug; Orchestration \(central state machine like Camunda or Temporal\) makes flow explicit and compensations easier to manage but creates coupling to the orchestrator. Most teams should prefer Orchestration for clarity when compensations are complex.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T15:26:23.098767+00:00— report_created — created