Evolution and Optimization of Ctrip's Vacation Price Engine (Engine 1.0 → 3.0)

Ctrip's vacation business offers many travel routes, departure cities, and schedule periods, with product prices composed of multiple resources; any change in a resource price impacts the overall product price.

To capture price changes quickly and improve calculation speed, the architecture has been iteratively refined through three major versions—Engine 1.0, 2.0, and 3.0—each addressing new bottlenecks while maintaining price accuracy.

The article defines key terms such as resource task units, schedule task units, schedule price, task volume, throttling (external and internal), and accuracy criteria, providing a clear business scope for the engine.

Engine 1.0 processed ~30 million schedule tasks serially, stored results in MySQL (synchronised to SQL Server), and used a Redis sorted‑set priority queue; it suffered from network errors, memory limits, single‑point failures, and slow task generation.

Engine 2.0 replaced Redis with Hermes, migrated task generation to a Spark cluster, and introduced resource‑specific optimizations: flight requests were aggregated by route (reducing tasks from 1.8 B to 350 M), hotel calculations were aggregated by destination (cutting calls to one‑tenth), and VBK products were handled separately to avoid duplicate work; these changes cut task‑generation time from 5 h to 1.25 h and reduced the computation cycle from two weeks to 1.5 days.

Engine 3.0 tackled MySQL I/O bottlenecks by switching to HBase, leveraging its multi‑version capability for instant rollback of erroneous price releases, and further accelerated task generation by having Spark directly push messages to resource queues; the hot‑task strategy was refined to increase calculation frequency for schedules with large price differences, expanding coverage and improving accuracy.

Performance results show a steady rise in price‑calculation accuracy across versions and a dramatic reduction in computation time, as illustrated by the accompanying charts.

In conclusion, the optimizations are interdependent; each speed gain introduces new pressures on services, and the architecture continuously evolves to meet the ever‑growing business demands.