1. Why ACID Does Not Scale Across Network Boundaries
In a microservices architecture, each service owns its private database. When placing an order requires reserving inventory in Service A, charging a credit card in Service B, and issuing reward points in Service C, a single local database transaction cannot span all three systems.
2. Two-Phase Commit (2PC) and Its Fatal Flaw
2PC uses a Coordinator to execute Phase 1 (Prepare) and Phase 2 (Commit). During Phase 1, participating databases hold exclusive locks on affected rows.
In cloud environments with variable network latencies, if the coordinator crashes or a network partition occurs, participant nodes remain locked indefinitely. 2PC is a blocking protocol that decimates availability and throughput.
3. The Saga Pattern: Local Transactions & Compensations
A Saga breaks a distributed transaction into a sequence of local transactions. Each local transaction updates its local database and publishes an event. If step 3 fails (e.g. credit card declined), the Saga executes compensating transactions backward (cancelling reserved inventory) to restore consistency.
4. Orchestration vs Choreography
Choreography (Event-Driven): Services listen to domain events and decide their next local step. Simple for small workflows, but hard to trace and debug as complexity grows.
Orchestration (State Machine): A centralized Orchestrator service commands participants what to do next. Easy to monitor, visualize, and implement timeouts and compensations.
Model this architecture on the HLDForge Canvas
Turn static box diagrams into living, collaborative systems. Drag and drop microservices, Kafka clusters, and cache tiers. Run automated SPOF detection and STRIDE threat modeling in real time.
Written by HLDForge Architecture Team
Principal Distributed Systems Architect
The HLDForge Architecture Team publishes practical engineering guides, real-world case studies, and high-concurrency blueprints to help engineers build scalable and fault-tolerant software.