How ICBC Transformed Its Legacy OLTP Systems with a Distributed MySQL Architecture

Database Transformation Background

ICBC’s traditional IT stack relied on mainframe + DB2, which could not meet the rapid expansion of internet‑based financial services. Four main challenges were identified: limited processing capacity, high operational risk, slow delivery cycles, and excessive cost of mainframe licensing and hardware.

The transformation goal was to build a flexible, open, efficient, and secure IT architecture that supports rapid business innovation.

Core Demands and Strategy

Key strategies included achieving high concurrency and scalability, implementing a two‑site‑three‑center disaster‑recovery model, reducing reliance on commercial products, embracing open‑source MySQL, and automating operations.

Shift from centralized to distributed architecture.

Move from proprietary to generic (IOE‑free) solutions.

Adopt open‑source technologies.

Transformation Development Journey

The migration began in 2015, with three phases:

Phase 1 – Prototype and Exploration (2016‑2017)

Personal account services were moved from mainframe to an open‑platform, validating MySQL‑based OLTP feasibility and establishing a migration roadmap.

Phase 2 – Basic Research and Pilot (2017)

Extensive research and pilot deployments of MySQL, including a production prototype launched in May 2017.

Phase 3 – Large‑Scale Implementation (2018 onward)

Enterprise‑grade MySQL services were built with distributed middleware, high‑availability designs, and cloud‑native deployment, supporting thousands of nodes and applications.

Technical Stack

The stack comprises distributed services, transaction frameworks, batch processing, caching, data reconciliation, messaging, configuration management, and DevOps tooling.

Distributed services to reduce coupling.

Two‑phase commit and message‑based distributed transaction framework.

Batch processing for large‑scale data operations.

Data reconciliation and compensation mechanisms.

Distributed messaging platform.

High‑Availability Design

MySQL semi‑synchronous replication with majority‑consensus ensures RPO = 0. Dual‑write in‑city replication and a Beijing disaster‑recovery center provide sub‑minute RTO.

Operations and Automation

Automation covers parallel installation, customizable monitoring and alerting, fault analysis, automated health checks, and a unified management platform that enables one‑click upgrades and both automatic and manual failover.

Containerization

MySQL was containerized to improve resource utilization, achieving a 4‑5× efficiency gain and supporting over 400 nodes, while preserving data persistence and service exposure.

Results

More than 120 applications, 2 000 + servers, and 2 500 + MySQL instances were deployed, handling up to 7 billion daily transactions (≈15 k TPS during peak events) with design targets of 30 k TPS. The architecture achieves RPO = 0, RTO < 60 s, and significant cost reductions by replacing mainframe and commercial database licenses.

Future Work

Planned initiatives include expanding cloud‑native services, building real‑time data exchange platforms, migrating remaining Oracle workloads, and exploring next‑generation distributed databases to maintain technological independence.