Evolution of Ctrip Account System: Domain‑Driven, Middle‑Platform, and Multi‑Region Architecture

Scai, a senior R&D manager at Ctrip, shares the evolution of the company's account system, which provides user management and authentication capabilities.

Domain‑driven redesign – As the monolithic account system grew, it was split into many specialized services (e.g., third‑party login, real‑name information). This caused performance, data‑consistency, and operational overhead problems. The domain‑driven refactor aims to (1) logically group related functionality and (2) keep the transformation transparent to business. The system is reorganized into three functional groups: core functions (account data, login state, logging), auxiliary functions (Token, captcha), and access functions (BFF layer, front‑end UI/SDK).

Read/write comparison process – To ensure safe migration, a complete and isolated comparison is required. Read comparison forwards mirrored traffic from the old code cluster to a new offline cluster for response comparison. Write comparison records production traffic, replays it against both old and new clusters, and compares outputs, storage changes, and emitted messages.

After domainization, core data changes are isolated within domain services, ensuring atomic operations and eliminating dirty data, while the reduced number of services and the introduction of a BFF layer improve stability and development efficiency.

Middle‑platform consolidation – To support multiple brands and business teams, the account system is turned into a middle platform. Key goals are reducing transformation complexity, enabling configuration‑driven capabilities, and offering diverse integration methods. A globally unique UID encodes the system ID, simplifying routing and reducing the need for extensive mapping tables. The middle platform now provides account lifecycle management, multiple login methods (password, SMS, social), login‑state management, and security/monitoring features.

Three integration approaches are offered: (1) UI integration via the platform’s front‑end, (2) front‑end SDK for lightweight customizations, and (3) backend integration where businesses build their own BFF layer using the platform’s token and captcha services.

Multi‑Region deployment – To achieve high availability and low latency, Ctrip adopts a two‑city three‑center architecture. User data is tagged with a region identifier and synchronized across regions using DRC with filtered bidirectional replication. Two routing schemes are described: (1) gateway‑level region lookup per request, and (2) client‑side region tag sent at login, allowing the gateway to route directly. The architecture consists of a gateway layer, internal services deployed per region, and a data layer with identical DB schemas and Redis caches synchronized via DRC.

Conclusion – Over years, Ctrip’s account system has transformed from a large monolith into a domain‑driven, middle‑platform, multi‑region service, reflecting both business growth and advances in internet engineering. The evolution will continue, guiding future system designs.