From Monolith to Microservices: Lessons from Three Generations of Payment Architecture

Architecture Generations Overview

The evolution of the payment platform is described in three architectural generations, each reflecting the scale of business, team size, and operational requirements.

First Generation (Monolithic WAR)

Single .war package built with MVC principles.

HTTP requests are handled directly by the application, which accesses the database without an intermediate service layer.

Inter‑service communication, when present, uses Hessian, raw HTTP, or socket protocols.

Some deployments add a firewall‑isolated core data store to protect sensitive data.

Suitable for small teams (≤10 developers) and low‑traffic scenarios; deployment often requires a brief downtime window.

Scalability can be achieved with external load balancers such as Nginx or F5.

Second Generation (Chimney / Smoke‑Stack)

Business growth leads to high coupling and maintenance overhead in the monolith.

Teams adopt a “copy‑paste, independent deploy” approach, creating loosely coupled services that are deployed separately (often called a chimney or smoke‑stack architecture).

Advantages: faster iteration, reduced impact of changes on unrelated modules.

Challenges: data migration between services, increased operational complexity, and the need for coordinated deployment pipelines.

Because a full rewrite would take months, the organization runs the second‑generation services in parallel with a planned third‑generation platform, allowing continuous business operation while the new architecture is built.

Third Generation (Micro‑service 3.0)

Adopts high‑performance RPC components (e.g., gRPC, Thrift) for inter‑service communication.

Implements large‑scale service governance: service discovery, circuit breaking, rate limiting, and centralized configuration.

Automated operations include CI/CD pipelines, container orchestration (Kubernetes or similar), and self‑healing deployment strategies.

Comprehensive monitoring covers real‑time metrics, tracing, and alerting to ensure system health.

Designed to support rapid market expansion, high concurrency, and frequent feature releases.

Domain Separation in the Third‑Generation Platform

The platform is divided into functional domains, each encapsulating a coherent set of business capabilities and exposing clean APIs to other domains.

Accounting Domain : Implements double‑entry bookkeeping. Sub‑modules include core accounting, business‑specific accounting, query services, and integration adapters for external accounting systems.

Clearing Domain : Manages bank integrations, message‑format translation, routing logic, reconciliation, and query interfaces.

Payment Domain : Guarantees transaction safety and cross‑system consistency. Contains payment core, query services, decision engines, and checkout (cashier) services.

Transaction Domain : Provides generic transaction primitives (creation, query, external product interfaces) and can be further split into micro‑services per business line.

Settlement Domain : Handles fund allocation, fee calculation, and settlement reporting.

Above these core domains sits a Product Layer that abstracts business‑specific logic. New products (e.g., biometric payment, new financial products) are built as lightweight applications that consume the underlying domain services without modifying them.

API Gateway (MAPI)

The external entry point is an API gateway named MAPI, which provides:

Protocol conversion (HTTP/HTTPS, gRPC, proprietary protocols).

Security enforcement (authentication, authorization, TLS termination).

Traffic control (rate limiting, load balancing, request shaping).

Graceful degradation and fallback mechanisms for high‑traffic spikes.

Operational and Migration Considerations

Design external services with versioning and backward compatibility from the outset to avoid costly adaptation layers later.

Maintain a strong operations team capable of automated deployment, health‑checking, and incident response.

When transitioning from first/second generation to the third, plan data migration paths, schema evolution, and consistency checks; senior architects should define migration scripts and fallback procedures.

Continuous monitoring and observability are essential to detect latency spikes, error rates, and resource saturation across micro‑services.

Adopting a micro‑service architecture therefore requires forward‑looking service design, robust governance, and disciplined operational practices to ensure that the system can scale with business growth while remaining maintainable.