Design and Optimization of a High‑Performance Flight Search and Pricing System
This article outlines the design, challenges, and performance optimizations of a large‑scale flight search and pricing platform, covering system requirements, architecture layers, caching strategies, indexing, real‑time data synchronization, memory reduction techniques, and high‑availability solutions to handle massive, low‑latency queries.
Quora's (Qunar) goal is to become the world’s largest Chinese online travel site, which imposes strict system requirements for flight search: the lowest possible price, coverage of every route, real‑time price updates, comprehensive user needs, and a smooth booking experience.
The flight domain presents unique challenges: extremely frequent inventory and price changes, massive rule sets (hundreds of millions of supplier and airline pricing rules), billions of potential price records, high QPS (over 3,000 searches per second translating to 15 million price calculations), and costly GDS data access.
To meet these demands the team adopted a distributed, on‑demand real‑time computation model with asynchronous messaging and stateless services, enabling easy horizontal scaling.
The search framework is organized into four vertical layers—application, aggregation, price‑source, and data—each isolated for independent development, traffic control, and graceful degradation, while vertical channels allow multiple suppliers to be processed in parallel.
CacheManager handles cache invalidation both actively (price or rule changes trigger immediate updates) and passively (hot routes have shorter TTLs), reducing database pressure dramatically.
Inter‑service communication uses Protobuf serialization with Gzip compression and Redis as a message bus, minimizing I/O and bandwidth usage.
The pricing engine stores supplier rules in per‑supplier MySQL databases; the sheer volume and update frequency of these rules required a new indexing approach.
An index library was built by streaming MySQL binlog events via Alibaba’s Canal, parsing and sharding rules by route, and writing them to distributed index tables while preserving order per route; periodic diff jobs ensure eventual consistency.
High availability is achieved with Zookeeper‑coordinated leader election for task distribution, automatic failover, and consistent hashing on route + supplier to balance load and keep cache hit rates high.
After applying local caching, memory‑saving encodings, and load‑balancing optimizations, memory usage dropped ~50%, the system sustained 50 k QPS with <50 ms latency, and GC pressure was greatly reduced.
Qunar Tech Salon
Qunar Tech Salon is a learning and exchange platform for Qunar engineers and industry peers. We share cutting-edge technology trends and topics, providing a free platform for mid-to-senior technical professionals to exchange and learn.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.