Design and Implementation of Ctrip Flight Order Itinerary System: Architecture, Sharding, Caching, and Structured Concurrency

Background : Ctrip's flight order system consists of multiple sub‑systems (ticketing, change, flight‑change, etc.) making real‑time aggregation of itinerary data complex, leading to high latency, mismatches, and incomplete information.

Goals : Provide accurate, up‑to‑date itinerary data; offer a one‑stop query interface; ensure high performance and reliability; increase automation; and enable rapid implementation of complex business flows.

Design Idea : Deliver precise latest itinerary, expose historical change traces, and support fuzzy matching for flight‑change scenarios.

System Architecture : Consists of a Data Collector API that gathers data from order, ticketing, change, and flight‑change sources, performs active + passive validation, and stores results; and a Query API offering itinerary query, trace query, and matching query with caching, circuit‑breaker, and rate‑limiting components.

Data Richness : Integrates 22 data sources via four update strategies – proactive notification, message‑driven consumption, real‑time query, and dynamic‑filter notifications – to balance freshness and load.

Convenience Enhancements : Replaces deep‑tree trace structures with graph‑like adjacency matrices (TripInfo nodes for vertices, ChangeInfo nodes for edges) for clearer, more usable relationship graphs.

Performance Optimizations :

Sharding the itinerary database by order‑id modulo to achieve horizontal scalability, with dual‑write handling, data migration, and secondary indexing to mitigate All‑Shard query overhead.

Introducing Redis cache with write‑through/delete‑on‑update, tiered storage, asynchronous back‑fill, null‑field omission, short key aliases, Zstd compression, and tuned TTL to reduce latency and memory footprint.

Adopting Java 21 Structured Concurrency and virtual threads to simplify multi‑condition matching logic, improve observability, and eliminate blocking overhead.

Results : Database QPS down 30%, CPU usage down 20%, average response time down 40% (P95 down 30%), thread count reduced 41%, and overall machine pressure significantly lowered, saving >50% of manpower for new features.

Future Plans : Add subscription notifications for itinerary changes, refine circuit‑breaker and degradation strategies, collaborate on new tech roll‑outs, explore new database designs, and build a visual dashboard for end‑to‑end itinerary insight.