2pc

How to Read This Post Each scenario shows a diagram first, then a short note on why the pattern matters. Complexity increases as you scroll. Pattern Approach Consistency Best For 2PC Coordinator-driven Strong (atomic) Short-lived, cross-DB 3PC Non-blocking 2PC Strong (reduces blocking) Theoretical improvement Saga Choreography Event-driven chain Eventual Loosely coupled services Saga Orchestration Central coordinator Eventual Complex workflows Outbox Pattern Local TX + relay At-least-once Event publishing guarantee Level 1 — Foundations 1. The Distributed Transaction Problem %%{init: {'theme':'dark', 'themeVariables': {'primaryTextColor':'#e5e7eb','secondaryTextColor':'#e5e7eb','tertiaryTextColor':'#e5e7eb','textColor':'#e5e7eb','nodeTextColor':'#e5e7eb','edgeLabelText':'#e5e7eb','clusterTextColor':'#e5e7eb','actorTextColor':'#e5e7eb'}}}%% flowchart TB C["Client: Place Order"] C --> OS["Order ServiceCreate order ✓"] C --> PS["Payment ServiceCharge $50 ✓"] C --> IS["Inventory ServiceReserve item ✗ FAILED"] IS -->|"What now?"| PROBLEM{{"Order created,payment charged,but no inventory!"}} PROBLEM --> Q1["Refund payment?"] PROBLEM --> Q2["Cancel order?"] PROBLEM --> Q3["Retry inventory?"] PROBLEM --> Q4["All of the abovein what order?"] style C fill:#4a9eff,stroke:#2d7ed8,color:#fff style OS fill:#51cf66,stroke:#37b24d,color:#fff style PS fill:#51cf66,stroke:#37b24d,color:#fff style IS fill:#ff6b6b,stroke:#d44,color:#fff style PROBLEM fill:#ffd43b,stroke:#f59f00,color:#333 style Q1 fill:#546e7a,stroke:#90a4ae,color:#fff style Q2 fill:#546e7a,stroke:#90a4ae,color:#fff style Q3 fill:#546e7a,stroke:#90a4ae,color:#fff style Q4 fill:#a29bfe,stroke:#6c5ce7,color:#fff The core problem. In a monolith, a single database transaction guarantees all-or-nothing. In microservices, each service has its own database — there’s no single transaction boundary. If one step fails after others succeed, you have an inconsistent state. ...