Why Distributed Core Banking Systems Are the Future of Legacy Bank Architecture

Overview

Bank core systems have evolved from single‑machine tape‑based installations to networked "fat" cores and now to lightweight, distributed cores. The core remains an electronic ledger whose autonomy is critical for national security.

1. Centralized Core Banking

Traditional cores consist of three major modules: deposits , loans and public services . The deposit module implements the most complex accounting functions—open, close, deposit, withdraw, transfer—and also handles account status control, transaction reversal, medium management and product‑rate configuration.

2. Business Middle Platform

Increasing system complexity creates information silos. An ESB‑based business middle platform integrates disparate subsystems, but it can only work if the core is first refactored into a set of atomic services that can be invoked independently.

3. Distributed Business Architecture

The distributed core is split into two logical layers:

Atomic service layer (bottom) – services are grouped by business domain (deposit, medium, product, cash, voucher, institution, etc.).

Composition layer (top) – aggregates atomic services either by business line or by payment vs. non‑payment to balance granularity and flexibility.

4. Distributed Technical Architecture

A complete technical stack is required, including:

Transaction routing and circuit‑breaker

Data routing middleware

Service registry (e.g., Nacos, Eureka)

Security and unified configuration

Governance platform for function, node and version management

Monitoring for latency, DB health, CPU/IO, etc.

5. Vertical Partitioning (Vertical Sharding)

Each business subsystem receives its own dedicated database. Tables that belong to a subsystem are moved to that database. For cross‑subsystem tables (e.g., institution‑product relations) the owning subsystem is chosen after a careful domain analysis.

6. Horizontal Partitioning (Horizontal Sharding)

Rows of a single table are distributed across multiple databases using a sharding key (typically the account number). A routing component examines the sharding key, applies a hash‑mod algorithm, and forwards the SQL statement to the correct shard. This enables account‑level data isolation, simplifies fail‑over and supports online data migration.

7. Horizontal Table Partitioning

MySQL tables that approach size limits are further split into partitions using the same routing rule as horizontal sharding, reducing per‑table size without changing the application logic.

8. Distributed Core Application Architecture

Online Transaction Flow

The composition layer receives a request, orchestrates calls to one or more atomic services, and records each step in a transaction‑log table. A saga‑style automatic compensation mechanism provides eventual consistency when a sub‑transaction fails.

Composition Layer

Responsibilities:

Pre‑processing checks (service and teller validation)

Visual workflow orchestration (generated code can be deployed as an interface)

Transaction splitting for account‑level sharding (debit and credit may reside in different shards)

Atomic Service Layer

Each subsystem exposes single‑purpose APIs (e.g., deposit.debit, cash.handle). Frequently used reference data (product parameters, blacklist/whitelist) is pushed to a shared public database to avoid cross‑service calls.

9. Batch Processing Architecture

Day‑end batch processing is transformed into a series of online transactions (“batch‑to‑online”). The three‑layer design mirrors the online flow:

Control layer – orchestrates the overall batch job, manages parallelism and ordering.

Composition layer – re‑uses the same orchestration logic as online transactions.

Atomic layer – executes the actual business logic.

Horizontal sharding forces the batch engine to route each task to the appropriate shard and to execute independent steps in parallel.

10. Data Management in a Distributed Core

Data Routing

Middleware uses the sharding key (e.g., account_no) to select the target database. An exception routing table stores explicit overrides for accounts that must be forced to a particular shard.

Online Data Movement

To move an account between shards:

Lock the account (record in a lock table).

Migrate all related tables to the target shard.

Update routing metadata.

Unlock the account.

This operation can be performed without downtime.

Online Data Migration (Dual‑Run)

During migration both the old and new cores run in parallel. The routing component duplicates the request to both systems. If the old system fails, the new transaction is rolled back; if the new system fails, the old transaction is rolled back. Routing decisions are based on the migration status of the account.

Node Failure Handling

In a MySQL sharded cluster:

Slave failure – resynchronize the replica.

Master failure – compare transaction logs from the composition layer with the surviving slave, identify missing transactions, lock affected accounts, and replay the missing entries. If the master cannot be recovered, compensate transactions are generated from the composition‑layer log.

11. Performance Considerations

Push frequently accessed reference data (e.g., product parameters, blacklist) into a shared cache or public DB to shorten call paths.

Reasonably split subsystems to keep cross‑service calls low.

Separate parameter tables from sharded tables to avoid cross‑shard joins.

Classify queries as precise (single‑shard) or imprecise (multi‑shard) and handle the latter asynchronously.

Implement global and transaction‑level caches for static data.

Parallelize independent checks (e.g., anti‑fraud) to reduce latency.

12. Representative Transaction Scenarios

Typical flows (cash deposit, cash withdrawal, account transfer, medium replacement, large‑deposit transfer, fee calculation, limit enforcement, relationship‑based pricing) illustrate:

How the composition layer orchestrates atomic services.

How sharding keys drive routing of debit/credit sides.

How saga compensation restores consistency on failure.

13. Characteristics of Distributed Banking Systems

Compared with centralized cores, distributed systems provide:

Horizontal scalability via shard addition.

Fault isolation – a node failure affects only the accounts hosted on that node.

Granular account‑level locking and migration.

Operational flexibility – rapid node deployment, independent service upgrades, and fine‑grained monitoring.

14. Sample Sharding Algorithm (illustrative)

function route(accountNo, shardCount):
    hash = murmur3_32(accountNo)
    index = Math.abs(hash) % shardCount
    return "shard_" + index

The algorithm can be extended with a range‑to‑shard mapping table to support online expansion without moving existing accounts.

15. Images