Saga Pattern

Prerequisite: Familiarity with the concepts introduced in Part 3 — Event Sourcing Cqrs. Review it first if the terminology in this part is unfamiliar. Answer-first: The Saga pattern coordinates distributed transactions across core banking microservices without two-phase commit (2PC). By executing local transactions and defining compensating actions for failures, Sagas ensure eventual consistency across payment and ledger services. Series (Part 4 of 8): This article builds upon Event Sourcing from Part 3. The Saga Pattern solves the problem: “How do we ensure consistency when a transaction must coordinate across multiple microservices without using distributed locks or 2PC?” ...

Answer-first: Modernizing core banking monoliths requires transitioning to event-driven microservices using Event Sourcing, CQRS, and the Saga Pattern. Emitting immutable domain events for every ledger mutation enables decoupled scaling, complete financial auditability, and sub-millisecond query responses across composable banking modules. Prerequisite: Part 3: Transaction Isolation and ACID Guarantees on database lock behaviors. Series context (Part 4 of 8): This guide assumes familiarity with ACID transactions and database concurrency. Understanding why consistency guarantees are hard at the database layer is essential context before introducing distributed patterns here. ...

Prerequisite: Familiarity with the concepts introduced in Part 8 — Phase3 Full Cutover. Review it first if the terminology in this part is unfamiliar. Answer-first: Distributed transaction consistency is achieved using a choreography-based saga paired with a PostgreSQL transactional outbox. Business mutations write to the outbox atomically. Background workers publish events to Dapr PubSub every 500ms, while idempotent consumer handlers process compensation events on failure. When a customer places an order on the Composable Commerce Platform, seven events need to happen in sequence across four independent services: Order created → Payment authorized → Stock reserved → Fulfillment triggered → Notification sent → Loyalty points awarded → Shipping label generated. Any of these can fail. The network can fail. The database can fail. A third-party payment gateway can time out. ...

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. ...

Composable Banking Architecture: Monolith to Modular Answer-first: The composable banking architecture pattern replaces monolithic core banking systems with modular, independent Packaged Business Capabilities (PBCs). By leveraging Go microservices, Saga orchestration, and the Strangler Fig migration pattern, banks can decouple their legacy ledgers without risky “Big Bang” cutovers. Migration Path from Monolith to Composable Transitioning to a composable core requires a phased approach to mitigate operational risk: API Gateway & Anti-Corruption Layer (ACL): Shield the legacy core behind a gateway and translate modern API requests into legacy formats using an ACL. Shadow Routing: Deploy the new composable service (e.g., a new Go-based ledger) in parallel. Mirror live traffic to it and reconcile the outputs without affecting actual customer balances. Incremental Cutover (Strangler Fig): Once reconciliation achieves 100% parity, route read traffic to the new service, followed by write traffic, effectively “strangling” that specific domain out of the monolith. Legacy core banking systems were designed in a different era. Temenos T24, Finacle, and Flexcube shared one defining assumption: the bank’s entire product catalogue — deposits, lending, payments, trade finance — would live inside a single, tightly coupled application and a single, shared database. That assumption held when banking moved at human speed. It breaks completely when product releases need to go from months to days, when a single fraud engine update must not risk a payments outage, and when engineers on a COBOL codebase are retiring faster than they can be replaced. ...

Banking Microservices in Go: Saga & Event Sourcing 1. Introduction: Deconstructing the Legacy Core Legacy banking platforms like Temenos T24 and Oracle FLEXCUBE were designed as rigid transactional monoliths for batch processing. Digital banking now requires decomposing these into event-driven microservices capable of real-time payments with sub-10ms latency. Migrating to a microservices architecture means dismantling these bottlenecks: Scaling limitations: Monoliths scale vertically (costly hardware), while microservices scale horizontally. Release cycles: Legacy cores require massive, risky quarterly releases. Microservices enable independent deployments. Data locking: Central databases in monoliths create severe lock contention during high-velocity events (like payday processing). By leveraging Go’s highly concurrent runtime and a distributed event-driven architecture, we optimize the system for <10ms database writes at 10,000 TPS, ensuring scalability and fault tolerance. ...

Architecting 21-Service E-commerce with Golang & DDD The exact performance overhead of using Go’s structural subtyping versus manual dependency injection in high-throughput microservices. Why scoping database transactions to a single Aggregate root is critical, and how we resolved out-of-order event delivery using Kafka partition keys. Scaling an e-commerce platform past 10,000+ orders per day containing multiple SKUs across dynamic warehouses is where naive architecture breaks down. Hardware scaling ceases to be a magic bullet when distributed transactions, race conditions, and eventual consistency are involved. ...