System Refactoring and Architecture Upgrade of Ctrip Vacation Product Platform

The article introduces the background of Ctrip's vacation product system, a legacy .NET platform using SQL Server that suffered from high business complexity, outdated architecture, replication delays, and low development efficiency.

Key problems identified include massive table count with unclear core/non‑core separation, replication lag affecting product sales, duplicated development across self‑operated and supplier systems, and risky data synchronization via WCF.

To address these issues, a comprehensive refactor was undertaken, focusing on two main areas: storage reconstruction and architecture upgrade.

Storage reconstruction involved migrating the database from SQL Server to MySQL, eliminating replication, and redesigning tables based on domain models. The migration was split into three phases: establishing a data‑sync API, implementing dual‑write to both databases, and finally cutting off the old SQL Server writes after verification. Monitoring and data‑compensation tools were built to ensure consistency.

Additional storage improvements included separating product and resource data into distinct tables, isolating core and non‑core data with different read/write patterns and disaster‑recovery requirements, and replacing polling with a message‑driven approach using Canal and system messages to achieve real‑time data propagation.

Architecture upgrade merged the previously separate self‑operated and supplier systems, reducing duplicate code and data sync overhead. The new design adopted a front‑end/back‑end separation: ReactJS for the UI and Java‑based APIs for the service layer, with MySQL as the primary store, Elasticsearch for indexing, and HBase for logs.

The upgraded architecture also introduced unified APIs, a centralized storage layer, and a message system to decouple downstream services, improving data safety, performance, and scalability.

In conclusion, the refactor delivered higher system availability, reduced development effort, better data real‑time consistency, and a more maintainable codebase, while highlighting three practical lessons: risk control through staged rollouts, respecting user workflows, and anticipating new challenges such as sharding complexity.