Evolution and Service Decomposition of Qunar's Payment System (1.0 → 2.0)

Lu Bo, a R&D engineer at Qunar's financial division, introduces the evolution of Qunar's payment system, which started in 2011 as a monolithic, high‑coupling solution (1.0) and grew over five years into a distributed, high‑concurrency, high‑availability platform supporting diverse payment scenarios.

1. Payment System 1.0

The initial system bundled all business logic into a single codebase to enable rapid feature delivery. Its core components included the cashier, transaction, payment, gateway, and accounting modules. While sufficient for low traffic, the monolith faced issues as business complexity increased, such as limited fault isolation, poor scalability, high development cost, and tangled responsibilities.

2. Payment System 2.0

Version 2.0 introduced service‑oriented decomposition to address the shortcomings of 1.0 and to support more complex business requirements.

2.1 Service Decomposition

2.1.1 Gateway Split

The gateway, a foundational service that abstracts payment, refund, and query operations, was extracted first to provide a stable base for external payment channels.

2.1.2 Accounting System Split

The accounting module evolved from simple transaction logging to a professional double‑entry bookkeeping system, enabling complex financial reporting.

2.1.3 Membership System Independence

The membership service was separated to clarify responsibilities, adding features such as real‑name verification, asset management, and transaction handling.

2.1.4 Base Service Split

Common functionalities (security, signing, notification, basic queries) were centralized into a shared base service (e.g., the Talos system).

Based on the transaction flow (order → transaction → cashier → payment → gateway → bank), the system was further split into dedicated services:

1. Transaction Core (Apollo)

Handles acquiring methods and various transaction types, supporting single and batch orders, direct, escrow, split‑payment, pre‑authorization, and post‑transaction operations.

2. Payment Core (Minos)

Manages payment method combinations (cards, Alipay, WeChat, vouchers, points, etc.) and supports mixed‑payment scenarios.

3. Cashier

Provides user‑facing payment pages across multiple platforms (native app, web, PC) to improve conversion rates.

4. API Access Layer

Exposes backend services via read‑write separated APIs (e.g., Ares for queries, Odin for write‑heavy operations).

The overall architecture is illustrated in the final diagram below, showing the integrated components and their interactions.

The article concludes by noting that subsequent posts will discuss challenges encountered during the service split, such as database migration, asynchronous processing, monitoring, and alerting.