Sharding and Database Refactoring for High‑Volume Train Ticket Orders at Ctrip

With the rapid growth of Ctrip's international train‑ticket business, order volume surged and the single‑database architecture began to show performance bottlenecks, prompting a complete redesign of the order database.

The team identified two main categories of challenges: generic sharding issues (how to split, shard key selection, routing, middleware choice, cross‑database transactions, data expansion) and business‑specific problems (direct application‑to‑database connections, smooth migration, historical data migration).

After evaluating vertical and horizontal splitting, the team chose horizontal database and table sharding because vertical splitting could not meet the required scalability. The shard key was selected based on business characteristics, using the order ID for the order system to avoid hotspot concentration.

Three routing strategies were examined: mapping tables, group routing, and hash routing. Mapping tables offered flexibility but introduced massive mapping data; group routing was simple but prone to hotspot issues; hash routing provided uniform distribution but made expansion difficult. The final solution combined group routing with hash routing (group‑hash routing) to gain easy expansion and balanced data distribution.

For middleware, several options were compared, and Sharding‑Sphere was selected due to its Java ecosystem compatibility, lightweight nature, customizability, active community, and performance that matched the team's requirements.

A dedicated service proxy named Dal‑Sharding was built to encapsulate all sharding logic, providing a unified API for all order‑related services and shielding them from sharding complexity.

To ensure a smooth transition, the team implemented dual‑read and dual‑write mechanisms. Dual‑read first attempts to read from the new database and falls back to the old one if necessary, while dual‑write writes to the new database and asynchronously replicates to the old one using a combination of aspect‑oriented programming, order‑event triggers, and scheduled tasks.

The migration was performed in three stages: first migrating low‑traffic new suppliers, then stable low‑volume online services, and finally the high‑traffic core services, each step verified by the dual‑read/write safeguards.

Data migration was carried out at the order level rather than table‑by‑table, extracting complete order information from the old database, transforming it to the new schema, and writing it to the new tables in a scheduled batch process.

After the refactor, the order database has been running stably in production, delivering benefits such as centralized service access, unified API management, flexible customization, transparent sharding routing, and comprehensive table‑level monitoring.

The article concludes with a FAQ covering typical sharding questions, including cross‑database operations, pagination, complex statistics, hotspot mitigation, and the rationale behind using multiple dual‑write techniques.