Transforming Legacy Payment Systems into Scalable Microservices: Real-World Insights

SOA, DDD and Microservices Evolution

Traditional Service‑Oriented Architecture (SOA) emerged before 2010 to split tightly‑coupled systems into coarse‑grained, stateless services. Microservices refine this idea by creating fine‑grained, independently deployable units that follow the single‑responsibility principle. Domain‑Driven Design (DDD), originally a UML‑centric modeling approach, provides bounded contexts, sub‑domains and domain events that map naturally to microservice boundaries.

Legacy Payment Platform Pain Points

The monolithic payment system suffered from:

Non‑scalable code and poor extensibility

Frequent database deadlocks and long‑running transactions

Insufficient fault tolerance and lack of idempotent operations

Excessive logging causing performance degradation

Configuration read from databases at runtime

Thread‑pool misuse leading to stack/heap overflow

Full‑table queries on read‑replicas

Cache stampede and penetration issues

Messy upstream/downstream workflow definitions

Inconsistent exception handling

Single‑cluster, single‑datacenter deployment with shared Tomcat instances

Manual packaging, deployment and scaling

Microservice Refactoring Principles

Product iteration speed : Decompose business functions into independent services to accelerate delivery.

System stability : Fine‑grained services isolate failures; comprehensive monitoring is added.

Rapid fault localization : Reduce mean‑time‑to‑detect (MTTD) to minutes.

Clear service coupling : Avoid monolithic coupling; split services wherever possible.

Low operational overhead : Automate deployment, scaling and recovery.

Domain Decomposition with DDD

Using DDD, the payment domain is divided into three sub‑domains—Cashier, Merchant and Personal. Each sub‑domain contains bounded contexts that correspond to individual microservices (e.g., Cashier has two contexts, Merchant four, Personal two).

Technical Stack

The target architecture adopts Spring Boot + Dubbo because the organization already maintains a “Dubbo Cloud” platform, making migration cheaper than switching to Spring Cloud.

Key components:

Self‑developed tracing probe that records request latency, error codes and parameters.

Probe pushes data to Kafka, aggregates in Redis, and drives real‑time channel selection.

Hystrix‑style circuit breaker integrated into the probe for automatic service degradation.

Channel Alarm & Routing System

Payments connect to multiple bank channels that vary in stability. An agent collects channel success metrics, writes them to Kafka, and stores aggregated scores in a Redis cluster. The routing service queries Redis, selects the highest‑scoring channel, applies additional filtering, and establishes the connection.

Alerts are emitted via SMS/email when a channel becomes unhealthy, and the system can automatically switch to a backup channel.

Dual‑Active Data Center Strategy

To satisfy regulatory requirements for multi‑active data centers, a two‑stage approach is used:

Pseudo‑dual‑active : Two sites run the same services; the standby site accesses the primary site’s database and Redis via dedicated links. In a primary‑site failure, the standby’s database configuration is promoted.

Lane‑based dual‑active : Zookeeper (ZK) synchronizes state using Curator TreeCacheListener or a custom Observer implementation that consumes transaction logs for near‑real‑time data replication.

Overall Microservice Panorama

The full stack consists of:

Domain‑level service segmentation (left side of the diagram).

Reliability layer: unified scheduling, dual‑active control, big‑data platform, distributed cache, and custom monitoring (right side).

APM‑style distributed tracing and internal monitoring platform.

Testing, CI/CD and Open‑Source Decisions

Testing strategy is divided into four quadrants:

Unit tests (JUnit, 60‑80% coverage).

Acceptance tests.

Exploratory/fault‑injection tests.

Stress tests.

Static code analysis, Gerrit code review and CI pipelines enforce quality before merge.

Component selection balances heavyweight open‑source solutions (e.g., Ctrip’s Apollo for configuration) against lightweight alternatives based on project needs. The “Dubbo Cloud” platform, built on Dubbo, is planned for open‑source release.

Future Work

Upcoming initiatives include:

Full multi‑active data‑center deployment to meet central‑bank regulations.

Open‑sourcing the Dubbo Cloud ecosystem.

Expanding the big‑data analytics layer for risk control and data mining.