From Two‑Site Three‑Center to Three‑Site Five‑Center: NetBank’s Database Architecture Evolution

Database Deployment Architecture Evolution

Database deployment architecture balances capacity, availability, performance, and cost. NetBank’s infrastructure progressed from an early distributed architecture for rapid business response, through a unit‑based design, to a cloud‑native era, with multiple iterations as business grew.

Disaster Recovery: From “Two‑Site Three‑Center” to “Three‑Site Five‑Center”

Initially, the bank used a “two‑site three‑center” model providing data‑center‑level disaster recovery but not city‑level. It later expanded to a “three‑site five‑center” architecture (3‑2‑1 deployment) where any city failure triggers primary‑node selection to maintain service continuity.

Distributed Database

Data appears as a logical whole but is physically spread across network nodes. Middleware or a coordination server routes read/write requests, providing proxy‑based control. A centralized proxy architecture enables applications to access multiple nodes transparently.

Distributed Transactions and Data Consistency

Transactions guarantee data accuracy and consistency, adhering to ACID properties. Distributed protocols such as Paxos or Raft ensure consistency across replicas. A typical 3‑replica setup (1 primary, 2 backups) writes to the primary and at least one backup before committing.

Atomicity : All operations succeed or none do.

Consistency : System remains in a valid state.

Isolation : Concurrent transactions do not interfere.

Durability : Committed changes persist.

Two‑phase commit is the common solution: the coordinator sends prepare to participants, waits for prepare OK, writes a commit log, then sends commit. If any participant aborts, the coordinator logs a rollback and sends abort to all.

Multi‑Tenant Strategy

A distributed database cluster can host multiple tenants by allocating separate database instances. Tenants receive isolated CPU, memory, storage, network bandwidth, and connection limits. Isolation extends to security (tenant‑specific users), fault domains, and operational management.

Application Latency Analysis and Optimization

The “three‑site five‑center” design adds cross‑city latency, affecting end‑to‑end latency, hotspot rows, and batch processing. Real‑time tracing middleware parses application and database logs to identify high‑latency SQL statements. Optimization directions include caching, deployment adjustments, SQL tuning, and asynchronous redesign.

Data Access Routing Policy

Two deployment modes exist: expansion (applications grouped by business) and mirroring (identical stacks in each data center). NetBank classifies data into three categories—traffic‑shippable, global, and global‑city‑level—and defines access priority: same‑room → same‑city → same‑city high load → cross‑city → cross‑city high load.

Multi‑Cluster Deployment

NetBank’s database clusters evolved from a few monolithic instances to multiple vertical and horizontal partitions (user, product, business, accounting, exchange, public). Early clusters used 5‑set sharding; later growth required dedicated clusters per business line to limit fault impact.

Containerized Deployment

Containerization increases the number of database clusters on limited physical machines, enhancing fault tolerance. Deployment steps:

Add container nodes and migrate a backup node to a container.

Replace remaining nodes with containers, promoting a container to primary with priority settings.

After validation, replace original ECS nodes with containers.

Containerization, combined with partitioning, provides both scalability and fine‑grained management for large‑scale banking workloads.