Distributed Transactions

Distributed Transactions in Go with Temporal Saga Pattern Distributed transactions in Go microservices are commonly implemented using the Temporal Saga pattern: replacing blocking Two-Phase Commit (2PC) locks with imperative workflow orchestration, dynamic reverse compensations (saga.AddCompensation), and PostgreSQL idempotency tables to keep financial event consistency during network partitions. This guide covers: The Zombie Activity Pitfall: Why setting StartToCloseTimeout without database-level idempotency locks causes phantom debits during prolonged TCP network partitions. Dynamic Compensation Registration: How to structure workflow.NewSaga in Go so that partial failures (e.g., debit succeeds, fraud check passes, but ledger credit fails) only execute compensation for steps that actually mutated state. Handling Non-Compensable External Side-Effects: Practical design patterns for handling third-party banking APIs (e.g., SWIFT/ACH wires) that cannot be programmatically rolled back. Workflow Determinism Invariants: How to write Go workflows that use Temporal signals and queries without triggering fatal non-deterministic replay panic errors. Section 1: FinTech Distributed Transaction Mechanics: 2PC vs Saga & Dual-Entry Accounting Invariants In modern distributed financial systems, microservice architectures decompose monoliths into autonomous domains: Account Management, Fraud Detection, Core Ledger, Payment Gateway Integration, and Customer Notifications. While this decomposition provides organizational velocity and independent database scaling, it shatters the traditional ACID guarantees provided by single-instance relational databases. ...

The Saga Pattern coordinates distributed transactions across microservices by decomposing a large transaction into a sequence of local transactions. If any step fails, the system automatically executes compensating transactions in reverse order to undo completed steps. Each local transaction must be idempotent. Prerequisite: Part 8 of the System Design Masterclass. Read Part 7: Idempotent API Design first — compensating transactions in Saga must be idempotent. What You’ll Learn Temporal Workflow Determinism: How Temporal’s event sourcing workflow engine replays Go code, and why random functions or time sleeps crash workers. Debezium EventRouter Tuning: The exact JSON configuration keys needed to customize Kafka routing keys and prevent partition ordering issues. Pivot State Analysis: Identifying the “point of no return” in a distributed saga where compensations are no longer allowed. What Are the Problems with 2PC in Microservices? Key Concept: Two-Phase Commit (2PC) is a blocking protocol with a coordinator single point of failure. If the coordinator crashes between the Prepare and Commit phases, all participants are blocked indefinitely with locks held — a catastrophic failure mode in microservices. These are the same core banking distributed transaction challenges seen in legacy systems. ...

Dapr Workflow Go Tutorial: Orchestrated Saga Pattern Compensation handlers configuration in Dapr to guarantee atomic rollback. How to handle transient workflows when the orchestrator instance restarts mid-transaction. Most Go developers building microservices know the Choreography Saga pattern: service A emits an event, service B reacts, service C reacts to B, and so on. If step C fails, services emit “compensation” events in reverse order. The pattern works elegantly for simple flows, but breaks down as the number of steps grows: debugging a failed saga requires tracing events across five message broker topics, and implementing compensation logic requires every service to understand the full saga’s state. ...