Optimizing Flight Ticket Pricing Search Performance at Qunar: Architecture, Bottlenecks, and Solutions

Background In 2018‑2019 the domestic flight pricing business at Qunar grew rapidly, adding new products such as auxiliary and student tickets, which caused request volume and computational complexity to surge, leading to severe response‑time degradation (search latency rose from ~200 ms to ~350 ms).

Basic Concepts and Analysis The system consists of three layers: the main system (aggregates pricing data), the pricing support layer (stores and elects optimal quotes), and the pricing source layer (provides raw fare data from agents and policies). The main bottlenecks are in fetching extended information and base pricing.

Structure The overall domestic pricing architecture is illustrated below:

The system can be divided into three layers: Main System, Pricing Support, and Pricing Source.

Main System This layer aggregates pricing data from various sources (agent fares, hotel fares, membership fares, etc.) and applies marketing rules such as discounts and rebates.

Analysis shows that latency mainly comes from fetching extended information and base pricing; other steps involve data transformation with limited optimization potential.

Search Structure Changes The OTA search returns all quotes for a single flight, while the list search returns only the lowest price per flight. By separating OTA processing in the pricing support layer, the computation per request drops dramatically, reducing average latency.

Overall average response time decreased by about 40% (400 ms → 230 ms).

Pricing Support Layer This layer stores quotes and performs election of the optimal quote. The election logic originally required up to 60 000 calculations for a typical search (50 flights × 30 products × 40 agents).

By classifying products (single‑trip, multi‑trip, non‑display) and limiting election to relevant types, the number of calculations was cut roughly in half.

Result: single‑trip average latency dropped from 250 ms to 200 ms.

Full Quote Retrieval Quotes are cached in Redis per agent. Long‑tail latency from slow agents was mitigated by introducing a circuit‑breaker that aborts after repeated timeouts, adjusting timeout ratios, and falling back to stale quotes only when necessary.

Online testing showed that circuit‑breaker adjustments affected only a few requests and had negligible impact on low‑price availability.

Final Effect Combining business‑driven restructuring with technical optimizations (asynchronous de‑duplication, data compression, serialization choices, GC tuning) yielded a total latency reduction of roughly 40% with minimal investment.