Financial Microservices Architecture: Saga & Ledger

Answer-first: Designing a secure financial microservices architecture: Utilizing Orchestrated Saga (Dapr), Double-Entry Bookkeeping, and Transactional Outbox.

In software engineering, UI glitches might annoy users, but financial discrepancies will kill a business and invite lawsuits. Building a robust financial microservices architecture for Fintech or Core Banking is one of the toughest architectural challenges you will ever face.

Whether you are managing a state-of-the-art GitOps deployment system or a complex order routing engine, designing for financial systems demands a completely different level of rigor. This article analyzes the mandatory Design Patterns required when building Banking Microservices.

The Challenge of Distributed Transactions in Core Banking

In a Monolith architecture, transferring money from Account A to Account B is trivial: you wrap both UPDATE SQL statements inside a single Database Transaction (ACID). If the system crashes midway, the database automatically rolls back everything.

However, in Microservices, Account A might reside in the User Service (using PostgreSQL), while Account B is in the Wallet Service (using MySQL). There is no single database to wrap the transaction for both. This is known as the Distributed Transaction problem.

If you successfully deduct money from Account A but fail to add it to Account B due to a network timeout, the customer’s money vanishes into thin air!

Solving Consistency with the Saga Pattern

To solve this problem without relying on Two-Phase Commit (2PC)—which is notoriously slow and causes database locking—architects employ the Saga Pattern.

A Saga is a sequence of Local Transactions. Each Microservice executes its own local transaction and emits an Event/Message to trigger the next step in the sequence.

Orchestrated Saga (Based on Dapr Workflows) vs. Choreographed Saga

There are two ways to design a Saga:

1. Choreography: Services listen to each other’s events without a central director. For example, Service A deducts money and emits a MoneyDeducted event; Service B catches that event and adds the money. This works for short flows, but when a transfer spans 5-7 services, you create a tangled web of events that is impossible to debug.
2. Orchestration: A central Coordinator directs the flow. For instance, using Dapr Workflows, the Coordinator commands: “Service A, deduct the money.” Once A confirms success, the Coordinator says: “Service B, add the money.”

In banking systems, an Orchestrated Saga is mandatory because it provides clear transaction state tracking (Pending, Failed, Success) required for auditing.

Designing Compensating Transactions for Failures

The ultimate rule of a Saga is: If step $N$ fails, the system must automatically invoke the Compensating Transactions of steps $N-1, N-2, \dots$ to restore the previous state.

If adding money to Wallet B fails, the Coordinator must send a Refund command back to Service A to return the customer’s money, ensuring Eventual Consistency.

Implementing Double-Entry Bookkeeping as an Immutable Ledger

Why You Must Never Overwrite a Balance Field

A common anti-pattern among junior developers is storing a user’s balance in a balance column inside a users table and continuously executing UPDATE users SET balance = balance + 100.

This is a deadly Anti-pattern in Fintech. If a balance discrepancy occurs, you will never know where the money went because the history of additions and subtractions isn’t reliably preserved.

Designing the Journal and Account Table Structure

The gold standard solution is applying Double-Entry Bookkeeping. Every financial transaction must be recorded as a journal entry and must be Immutable—you are never allowed to UPDATE or DELETE a committed record.

CREATE TABLE accounts (
    id UUID PRIMARY KEY,
    type VARCHAR(50) -- Customer, Revenue, Suspense
);

CREATE TABLE ledger_entries (
    id UUID PRIMARY KEY,
    transaction_id UUID NOT NULL,
    account_id UUID NOT NULL,
    amount DECIMAL(18,4) NOT NULL, -- Positive (Debit), Negative (Credit)
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- Production-critical: without this index, SUM(amount) for a balance
-- calculation requires a full table scan across all ledger_entries.
CREATE INDEX idx_ledger_account_time ON ledger_entries (account_id, created_at DESC);

Every transaction inserts at least two rows into ledger_entries such that the sum of the amount always equals 0. A customer’s Balance is not a hardcoded column; it is calculated by executing a SUM(amount) WHERE account_id = ? across their ledger history.

Distributed Systems Note: In a microservices architecture, services on different nodes experience clock skew. Using created_at TIMESTAMPTZ alone for strict event ordering is unreliable. For guaranteed monotonic ordering across distributed services, pair created_at with a Snowflake ID or similar monotonic sequence generator as the transaction_id.

Preventing Event Loss with the Transactional Outbox Pattern

Solving the Dual-Write Problem (Writing to DB vs. Sending an Event)

In a Saga, after deducting money (writing to the DB), a service must send a notification to Kafka/RabbitMQ. What happens if the DB write succeeds, but Kafka is down and the message fails to send? The Saga breaks mid-flight. This is the Dual-Write Problem.

The Transactional Outbox completely resolves this. When deducting money, the service simultaneously saves the Event payload into an outbox_events table within the exact same Database Transaction as the deduction. Thanks to local ACID properties, either both succeed, or both fail together.

Leveraging CDC (Debezium) to Poll the Outbox Table

Instead of writing a continuous SELECT loop to poll the outbox_events table (which wastes DB CPU), modern systems use Change Data Capture (CDC) tools like Debezium.

Debezium reads directly from the MySQL Binlog / PostgreSQL WAL. Whenever a new row is inserted into the Outbox table, Debezium instantly captures the data and fires it straight into Kafka without impacting the primary database’s performance.

Ensuring Idempotency for Banking Endpoints

Due to the nature of distributed networks, messages (Events) can be delivered multiple times (At-Least-Once Delivery).

Imagine the DeductMoney($100) event being sent by Kafka 3 times due to network retries. If your API isn’t designed carefully, the customer gets charged $300!

All APIs handling financial transactions must be Idempotent. This is achieved by:

• The client sending a unique Idempotency-Key (or Transaction ID) with every request.
• The server checking a processed_transactions table: If this ID has already been successfully processed, the server immediately returns the cached success result (without deducting money again).
• If the ID does not exist, the server deducts the money and writes the ID to the table. Both of these actions must happen in a single DB Transaction, which implies having a robust MySQL database scaling strategy if your transaction volume is massive.

Designing a payment system architecture leaves no room for guesswork. The combination of Saga Orchestration, an Immutable Ledger, the Outbox Pattern, and Idempotent APIs forms the strongest armor to protect millions of dollars in daily transactions on your platform.

For how these microservices patterns apply in the microfinance vertical — group-based JLG lending, compulsory savings CASA logic, and EOD batch state machines — see Microfinance Core Banking System: Architecture & Engineering Guide.

FAQ