Bank Core System Design

The bank core system is the heart of financial institutions, carrying all critical business operations such as deposits, loans, and transfers. Its design must strictly adhere to ACID properties (Atomicity, Consistency, Isolation, Durability) to ensure absolute accuracy and security in fund data. In modern technology stacks, building a scalable and highly available core system typically adopts a distributed microservices architecture while relying on eventual consistency models to balance performance with data reliability.

Distributed Transaction Processing Mechanism

In a distributed environment, traditional Two-Phase Commit (2PC) can provide strong consistency guarantees but suffers from blocking risks and poor scalability. Therefore, modern banking systems tend to use transaction schemes based on TCC (Try-Confirm-Cancel) or the Local Message Table pattern. Taking TCC as an example, it ensures business logic integrity through three stages:

1. Try Stage: Attempt to execute business operations and reserve resources (e.g., freeze deposit balances). At this stage, actual deduction is not performed; funds are merely marked as "locked".
2. Confirm Stage: If the Try phase succeeds without exceptions, formally execute the deduction or transfer action.
3. Cancel Stage: If the Try phase fails or Confirm is not executed, it must rollback the reserved resource state.

For example, when initiating an inter-bank transfer, the system first calls the TCC Try interface to freeze funds in the source account and lock available quotas in the target account. Only after confirming that network latency has been eliminated and both services have responded successfully will the Confirm stage be entered to complete the actual deduction; if any link times out or throws an error, the Cancel phase will automatically release occupied resources to prevent fund loss accidents such as "money being locked up and unusable".

Data Consistency Assurance Strategies

Although distributed systems cannot achieve global strong consistency, bank core business requires extremely high standards for eventual consistency. To this end, systems often adopt a combination strategy of "compensation mechanisms + asynchronous queues". When the main transaction chain experiences delays due to performance bottlenecks or temporary failures, background message queues will continuously retry incomplete compensation tasks until data synchronization is completed.

Furthermore, critical fields such as account balances are typically stored in relational databases (such as PostgreSQL or MySQL), utilizing their built-in row-level locking and transaction mechanisms to guarantee single-point strong consistency; while high-frequency read/write ledger accounts and transaction details—non-core data—are migrated to NoSQL storage (such as Redis Cluster or Cassandra). This achieves alignment with the primary database through periodic full synchronization or Change Data Capture (CDC) of incremental logs. This layered storage architecture meets the rigor requirements for core accounting while enhancing overall system read-write throughput.

High Availability and Disaster Recovery Design

Banking systems must possess disaster recovery capabilities at the "Two Sites, Three Centers" level to cope with extreme scenarios such as regional or nationwide network interruptions and data center failures. Typical high-availability architectures include the following elements:

• Multi-active Deployment: Business logic runs synchronously across multiple geographic regions; each region can independently handle transaction requests without blocking others.
• Dynamic Traffic Scheduling: Through a global load balancer (such as Nginx or F5), requests are allocated in real-time based on the load status of each center to avoid single-point overload.
• Automatic Failover: When a data center detects heartbeat loss or service unavailability, the system automatically redirects traffic to a standby center and gradually takes over its business state in the background.

For example, if an unexpected large-scale attack causes a service avalanche in the East China region, the system can redirect new transaction requests to South China or Southwest data centers within milliseconds while smoothly switching the database write path via master-slave replication mechanisms to ensure zero interruption of services.

Security Compliance and Audit Tracking

The highest standard for financial systems is security. All core operations must undergo strict permission verification, encrypted transmission, and signature validation. Every transaction record must generate an immutable complete log chain containing operator information, timestamps, IP addresses, original instructions, and result status for post-event audit and regulatory inspection purposes.

The system also integrates a real-time risk control engine that utilizes machine learning models to identify abnormal transfer behaviors (such as large amounts of frequent transactions within a short time or login from remote locations) and intercept suspicious requests at the millisecond level. All sensitive data is encrypted using national cryptographic algorithms during transmission and storage, eliminating risks of information leakage.

Through the above architectural design, bank core systems can support high-concurrency transaction demands for hundreds of millions of users while ensuring absolute data security, serving as a solid foundation for modern financial infrastructure.