[System Design] Banking Microservices Architecture: Event...

Series context (Part 4 of 8): This article 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.

Why Microservices in Banking?

Microservices in banking is the architectural pattern where a core banking system is broken into independently deployable, domain-owned services (CIF, Payments, Lending, Notifications) connected by an event bus instead of direct database calls. This replaces monolithic systems like T24 or Flexcube — where a single change to the Payments module requires redeploying the entire application and risks taking down unrelated services.

High-risk deployments: Modifying a small module requires redeploying the entire system. A patch to the Payments module can take down CIF.
Inefficient scaling: You cannot scale just the Payments module during peak loads without scaling everything else — including parts that don't need more capacity.
Technology lock-in: Bound to a single programming language and database. Adding a modern ML risk engine becomes an 18-month integration project.

The current trend is transitioning to Headless Core Banking — decoupling the domain logic from the delivery channels (Mobile App, Internet Banking, ATM) using a banking microservices architecture.

Overall Architecture

                    ┌─────────────────────────────────────┐
  CHANNELS          │  Mobile App  │  Internet Banking  │  ATM/POS  │
                    └──────────────────────┬──────────────────────────┘
                                           │ REST/gRPC
                    ┌──────────────────────▼──────────────────────────┐
  API GATEWAY       │         API Gateway (Auth, Rate Limit, Routing)  │
                    └──────────────────────┬──────────────────────────┘
                                           │
         ┌─────────────────────────────────┼──────────────────────────┐
         │                                 │                          │
  ┌──────▼──────┐               ┌──────────▼─────────┐    ┌──────────▼──────────┐
  │ CIF Service │               │  Account Service   │    │ Payment Service     │
  │ (Customer)  │               │  (CASA, GL)        │    │ (Transfers, Fees)   │
  └─────────────┘               └────────────────────┘    └─────────────────────┘
         │                                 │                          │
         └─────────────────────────────────┼──────────────────────────┘
                                           │ Events (Kafka/Dapr)
                    ┌──────────────────────▼──────────────────────────┐
  EVENT BUS         │              Message Broker (Kafka / Redis)      │
                    └──────────────────────┬──────────────────────────┘
                                           │
         ┌─────────────────────────────────┼──────────────────────────┐
         │                                 │                          │
  ┌──────▼──────┐               ┌──────────▼─────────┐    ┌──────────▼──────────┐
  │ Loan Service│               │ Notification Svc   │    │ Reporting Service   │
  │ (Lending)   │               │ (SMS, Push, Email) │    │ (CQRS Read Side)    │
  └─────────────┘               └────────────────────┘    └─────────────────────┘

Pattern 1: Event Sourcing for the Ledger

In traditional architectures, we store the current state. In Event Sourcing, we store a sequence of immutable events that produce that state.

Why does Event Sourcing fit Core Banking?

The ledger is already essentially Event Sourcing — every entry is an immutable event. The current balance is simply the result of replaying all entries from the beginning.

// Events in the Account domain
type AccountOpened struct {
    AccountID    string
    CIFNumber    string
    Currency     string
    OpenedAt     time.Time
}

type MoneyDeposited struct {
    AccountID     string
    Amount        int64
    TransactionID string
    OccurredAt    time.Time
}

type MoneyWithdrawn struct {
    AccountID     string
    Amount        int64
    TransactionID string
    OccurredAt    time.Time
}

// Calculate balance by replaying events
func calculateBalance(events []Event) int64 {
    var balance int64
    for _, event := range events {
        switch e := event.(type) {
        case MoneyDeposited:
            balance += e.Amount
        case MoneyWithdrawn:
            balance -= e.Amount
        }
    }
    return balance
}

Pattern 2: CQRS — Command Query Responsibility Segregation

Core Banking has a unique characteristic: writes must be exceptionally robust (ACID) but reads need to be lightning fast (dashboards, reports). CQRS completely separates these two flows:

WRITE SIDE (Command)                READ SIDE (Query)
────────────────────────            ──────────────────────────
POST /transfers            →        Materialized Views
POST /accounts             →        Elasticsearch Index
PUT /loans/repay           →        Redis Cache

↓ Event Published ↓                ↑ Subscribe & Update ↑
         └──────────────────────────┘
              (Event Bus / Kafka)

Real-world Example:

Write Side: Processes transfers using PostgreSQL with full ACID compliance, guaranteeing money isn't lost.
Read Side: Dashboards display transaction history from Elasticsearch — ultra-fast queries, full-text search, and multi-condition filtering.

Pattern 3: Saga — Distributed Transactions Across Services

When a cross-bank transfer requires coordinating 3 services: Account Service (deduct money), Payment Service (send to clearing house), and Notification Service (send SMS), how do you ensure integrity?

Choreography Saga (Event-Driven)

Account Service                Payment Service           Notification Service
      │                               │                          │
      │── TransferInitiated ──────────▶│                          │
      │                               │── PaymentSubmitted ──────▶│
      │                               │                          │── SMS Sent
      │◀── PaymentCompleted ──────────│                          │
      │                               │                          │
   (release hold)                                            (done)

If Payment fails:
      │◀── PaymentFailed ─────────────│
      │                               │
   (cancel hold, refund)

Outbox Pattern — Guaranteeing Events are Never Lost

Problem: What if a service successfully commits to the database but fails to publish the event to Kafka?

Solution: Write the event to the database within the same transaction, then have a separate worker read and publish it to Kafka.

-- Outbox table: written in the same transaction as business data
CREATE TABLE outbox_events (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    topic       VARCHAR(100) NOT NULL,  -- 'account.transfer.completed'
    payload     JSONB        NOT NULL,
    status      VARCHAR(20)  NOT NULL DEFAULT 'PENDING',
    created_at  TIMESTAMPTZ  NOT NULL DEFAULT NOW(),
    published_at TIMESTAMPTZ
);

-- Inside the same Database Transaction:
-- 1. Update account balance
-- 2. Write ledger entries  
-- 3. INSERT into outbox_events

-- Separate worker running periodically:
-- SELECT * FROM outbox_events WHERE status = 'PENDING'
-- → Publish to Kafka
-- → UPDATE status = 'PUBLISHED'

API Design for Financial Transactions

Design Principles

Stateless APIs: Every request must contain all necessary information.
Mandatory Idempotency headers for all state-changing APIs.
Strict separation between Request (commands) and Status (polling).

POST /v1/transfers                    → Initiate transfer command
  Header: Idempotency-Key: <uuid>
  Body: { from, to, amount, currency }
  Response: { transfer_id, status: "PROCESSING" }

GET  /v1/transfers/{transfer_id}      → Check result
  Response: { status: "COMPLETED" | "FAILED", ... }

Never design a transfer API as a synchronous block because processing through a central clearing network (like SWIFT) can take anywhere from seconds to minutes.

Technical Stack Selection

Layer	Popular Choices	Reason
Service Framework	Go (Kratos, Fiber), Java (Spring Boot)	High performance, type-safe
Primary Database	PostgreSQL	Strong ACID, flexible JSONB
Cache	Redis	Balances, sessions, rate limiting
Event Bus	Apache Kafka, Dapr PubSub	Durable, ordered, replayable
Service Mesh	Istio, Dapr	mTLS, circuit breaking
Orchestration	Kubernetes	Auto-scaling, self-healing

References & Further Reading

🔗 Previous Step: Explore the foundational database layer in Part 3 — Database Design for Financial Transactions (ACID & Concurrency).

🔗 Next Step: Now that you understand banking microservices architecture and its event-driven patterns, see how these services communicate with the outside world through international financial standards. Continue reading Part 5 — International Integration Standards: ISO 8583 & ISO 20022.

🔗 Deep Dive: For a complete engineering guide to the full composable banking stack — ledger concurrency patterns, Strangler Fig migrations, RFC 8705 mTLS, and the next-gen vendor landscape — see Composable Banking Architecture: From Monolith to Modular Core.

This post was originally published on my blog at Banking Microservices Architecture: Event Sourcing, CQRS & Saga Patterns for Core Banking.

Hi, I'm Lê Tuấn Anh (vesviet) 👋
I am a Senior Go Backend Architect & Distributed Systems Engineer with 17+ years of experience building high-traffic platforms (25M+ requests/month).
If you enjoyed this deep-dive, let's connect on LinkedIn or explore my consulting services at tanhdev.com/hire.

推荐订阅源

DEV Community