Design and Implementation of Ctrip's Unified Accounting Platform

The original Ctrip accounting systems were built independently for each business line, sharing some common concepts but also exhibiting significant differences; all could be abstracted to account opening, bookkeeping, and auditing. To simplify development, operation, and front‑end support, a unified accounting mid‑platform was planned.

Key objectives of the new platform were agility (rapidly adapting to business changes), decoupling (isolating functional modules), and reusability (leveraging common components).

System Overview

Phase 1 (2014) used Zeroc ICE for RPC, RabbitMQ for messaging, and self‑managed Redis clusters. It supported single‑user, single‑account transactions such as recharge, payment, refund, pre‑authorization, withdrawal, and transfer.

Phase 2 upgraded to Ctrip’s Java stack (SOA, qconfig, qmq, qschedule) and added accounting and end‑of‑day processing.

Problems with the legacy core included insufficient abstraction, lack of isolation, no downgrade strategy, and scaling difficulties.

Goals of the Unified Platform

Abstraction

Isolation

Easy scaling

Configuration‑driven

Support for multiple institutions and currencies

System Architecture and Components

The platform consists of a scenario‑code system, front‑end gateway, core accounting system, account management, accounting system, asynchronous system, job system, and logging system, with services decoupled via Dubbo.

Front‑end gateway: handles transaction interfaces (deposit, withdrawal, pre‑authorization, transfer, batch).

Core accounting: records account movements for merchants, users, and internal accounts.

Management system: provides CRUD and status operations for merchants, users, and internal accounts.

Accounting system: uses double‑entry bookkeeping based on entry rules.

Base service system: offers configuration queries for subjects, entries, transaction codes, etc.

End‑of‑day system: audits and validates data from bookkeeping and accounting.

Logging Component

Replaced Logback with high‑performance Log4j2, added Spring AOP annotations for automatic logging of method parameters, return values, and exceptions, enabled tag propagation via ThreadContext, supported configurable masking of sensitive data, and integrated synchronous (company‑wide Clog/CAT) and asynchronous (Kafka) log delivery.

Sharding Component

Evaluated Dal cluster, QDB, Mycat, and chose open‑source Sharding‑JDBC for lightweight, configurable sharding (precise, range, composite, hint) with XML/YAML/Java API support.

Front‑End System Design

Standardized transaction interfaces using a scenario‑code model that maps product codes and transaction types to sub‑account IDs, allowing default and custom scenario codes.

Asynchronous Processing

Converted non‑critical synchronous calls to asynchronous Kafka messages (e.g., inbound deposits for transfers, accounting pushes) to reduce response latency.

Database Strategy

Implemented two‑layer data isolation (domain and physical sharding). Mapping DB stores request‑to‑front‑end ID relations; transaction DB stores all transaction records, with reverse transactions co‑located for transactional consistency.

Hash‑based routing distributes requests across mapping shards; weight‑based sharding distributes transaction tables, supporting graceful scaling and automatic failover.

Exception Handling

Idempotency for all interfaces.

Retry mechanisms (internal, job compensation, upstream).

Query interfaces for transaction status.

Notification mechanisms for success/failure.

Atomic System Design

Uses a responsibility‑chain pattern for order splitting and execution, with synchronous and asynchronous executors handling different bookkeeping models (account, activity, fund, daily book, order book).

Accounting System Design

Adopts double‑entry bookkeeping with configurable clearing rules (single, aggregated) and dynamic subject configuration for multi‑subject scenarios.

Daily Settlement System

Generates snapshots, sub‑ledger, and general ledger; performs balance and transaction amount reconciliation, total‑sub‑ledger checks, and audit detail verification to ensure 100 % accuracy for 24‑hour operations.

Challenges include continuous 24‑hour accounting, snapshot generation, and complex testing; solutions involve snapshot‑based balance checks, aggregated transaction updates, and task‑oriented job orchestration.

Conclusion

The unified accounting platform now supports Ctrip’s internal business needs and provides a configurable foundation for future extensions such as distributed transactions, hot‑account handling, and streamlined onboarding of new institutions.