Challenges and Solutions for Transforming Traditional Payment Systems to Distributed Architecture

With the rise of mobile and aggregated payment methods, traditional IOE‑centric payment systems face massive user growth, performance bottlenecks, and high scaling costs, while regulatory requirements demand high availability and robust disaster recovery.

To address these challenges, a distributed transformation is required; its core idea is to eliminate single points of failure by applying both vertical (service‑oriented) and horizontal (sharding) splitting.

Vertical splitting breaks the monolithic system into independent business modules based on an application architecture that includes four layers: channel layer, product layer, common service layer, and core business layer, plus supporting systems such as gateways, operation support, and security. Each module owns its data and communicates via exposed services.

Horizontal splitting classifies data into transaction‑type (流水型), state‑type (状态型), and configuration‑type (配置型). Transaction data is naturally sharded by user dimension using a two‑digit shard number embedded in generated IDs, enabling efficient split‑by‑user databases and tables. State data may also be sharded for concurrency, while configuration data is typically cached (e.g., Redis) rather than sharded.

After migration, several new problems arise:

Distributed transactions appear, often solved with TCC rather than XA.

Cross‑shard queries become difficult; solutions include data redundancy, asynchronous billing systems, or using heterogeneous indexes such as Elasticsearch.

Data synchronization to big‑data platforms (e.g., Hadoop) requires a data‑model management platform to subscribe to logical tables.

Batch processing (daily reconciliation, settlement) needs a three‑layer scheduling framework (split → load → execute) to parallelize work across shards.

Capacity expansion is handled by pre‑allocating shards and adding database servers without changing shard rules.

Disaster recovery strategies include same‑city active‑passive, remote cold standby, and remote multi‑active deployments, each with tailored data‑type protection.

Operational monitoring and tracing rely on distributed tracing (e.g., OpenTracing) and APM tools to diagnose issues across services.

In summary, distributed architecture offers massive scalability, cost efficiency, stability, and speed, but it is not a silver bullet; successful transformation demands thorough business analysis, careful architectural design, appropriate sharding strategies, and robust middleware support.