Why Unitized Architecture Is the Key to Scalable Financial IT Systems

Why Unitized Architecture?

Large financial institutions (e.g., assets > 1000 billion RMB) must operate a two‑site three‑center disaster‑recovery topology to guarantee continuous service. Traditional same‑city active‑active or remote disaster‑recovery setups waste resources because remote sites are often idle and cannot provide real‑time failover. Long‑distance links (≈20 ms one‑way, 60 ms round‑trip) make cross‑data‑center calls extremely slow; a single transaction that triggers dozens of service calls can take minutes, which is unacceptable for banking services.

What Is Unitized (Set‑Based) Architecture?

A unit is a self‑contained collection that includes all micro‑services, middleware, and the subset of data required to execute a complete business flow. Units are deployed in every data‑center site; each unit can independently handle the full set of business functions. Data is typically sharded by a uniform dimension such as user_id, so each unit stores only its slice of the global dataset. Traffic is routed to a unit based on the same dimension, ensuring that a transaction stays within a single data‑center and avoids cross‑city latency.

Core Capabilities of a Unitized Support Platform

Intra‑unit middleware suite : micro‑service framework, messaging system, and data‑access layer that guarantee all service calls for a transaction are resolved inside the same unit.

Rule‑management and traffic‑allocation system : defines routing rules (e.g., user_id % N), matches traffic to the appropriate unit, and enforces cross‑unit access policies. During a disaster it can re‑allocate traffic from failed units to healthy ones, acting like a traffic police.

Unit‑focused release, deployment, and monitoring : supports independent publishing, gray (canary) releases, health‑check probes, and per‑unit metrics. This enables elastic scaling (adding or removing units for peak events such as Double‑Eleven or Chinese New Year) and rapid isolation of faulty units.

Step‑by‑Step Construction Process

Refactor the business system : redesign data models and service interfaces so that data can be partitioned and traffic routed according to a single dimension (commonly user_id). Identify data that cannot be sharded and design fallback handling (e.g., shared reference tables).

Build the unit‑support platform : implement the three core capabilities listed above, exposing them as APIs or configuration services for developers. Ensure the platform abstracts deployment complexity and provides tooling for unit creation, scaling, and monitoring.

Design the unit topology : decide the number and type of units (e.g., core banking, payment, risk) and define routing rules for each traffic class. Document the mapping between logical business domains and physical units.

Migrate gradually : keep the existing “Center” cluster operational, incrementally provision new units, and shift traffic to them based on the routing rules. Validate each migration step with functional and performance tests before proceeding to the next batch.

With this approach, each data‑center hosts a complete set of units, eliminating cross‑city service calls while preserving the ability to scale horizontally by adding more units. The architecture also simplifies disaster recovery: if a data‑center fails, traffic can be rerouted to equivalent units in other locations without breaking transaction integrity.