Real-Time Flight Ticket Pricing Search System Architecture at Qunar
This article describes how Qunar’s senior architect designed a high‑availability, high‑performance, real‑time flight ticket pricing search system, discussing user requirements, challenges, and the backend architecture choices such as on‑demand computation, caching, MQ‑Redis integration, and layered system design.
This is the first of a three‑part series.
Zhu Shizhi is a senior architect at Qunar, serving as the International Ticket Technical Director. He joined Qunar in 2013 and has worked on public services and the international ticket search system, building a real‑time search and pricing system that handles high availability, high performance, massive data, and strong scalability.
User Demands and Challenges
User Demands
For users of the Qunar platform, the demands are simple: they want to purchase low‑price airline tickets easily. The main aspects are:
Comprehensive pricing: coverage of routes and flights should be complete.
Low price: the price must be advantageous and not exploit users.
Accurate price: real‑time and bookable.
Diverse products: meet varied needs of business travelers and price‑sensitive users.
Challenges
Although user demands are straightforward, building a system to satisfy them is complex. Flight ticket pricing search is a real‑time computation system. Airline fare rules, agency price adjustments, and inventory information change frequently, and massive data changes dramatically increase pricing calculation complexity. Moreover, some fundamental resources are owned by GDS (Global Distribution System) rather than Qunar, requiring fees to obtain.
The basic price generation process involves airlines setting fares for routes, publishing fares and seat inventory to GDS, and agents buying tickets with discounts.
Thus, a basic ticket price requires airline fare + inventory + distribution agency price adjustments, followed by packaging of ancillary information such as change‑fee policies, taxes, and optional add‑ons like Wi‑Fi or check‑in services.
Data volume is huge; the article includes several illustrative figures (images omitted here).
System Architecture
Given this background, the system must be designed to handle massive data computation.
Design Considerations
Two main approaches exist: full pre‑computation and on‑demand real‑time computation, each with pros and cons.
Full pre‑computation calculates all prices in advance and re‑computes affected prices when changes are detected, offering fast response and high accuracy but consuming enormous resources, especially under frequent changes.
On‑demand real‑time computation triggers calculation when a user searches, using result caching to reduce load. This approach requires fewer resources and scales better, though response time is slower and caching may affect price freshness.
Considering resource usage and scalability, the on‑demand real‑time approach was chosen, with further optimizations planned for speed and accuracy.
The system is horizontally layered, with the top layer serving various client channels (APP, web, low‑price). Below is a pricing aggregation layer that maintains a global cache managed by a cache manager, ensuring validity before serving cached results.
The next layer is the pricing engine layer, communicating with the aggregation layer via message‑driven interaction using MQ and Redis, which decouples components and allows independent addition or removal of pricing engines.
Within the pricing engine layer, two sub‑layers exist: a broader non‑core airline business layer (route planning, product packaging, multimodal transport) and a core ticket pricing calculation layer handling TTS, flagship stores, crawling, etc., with parallel engines providing complementary advantages.
The bottom layer is the data layer, containing fare rules, price adjustment rules, flight data, and a mix of storage/query services and real‑time calculations (e.g., fares are computed in real time rather than pre‑computed).
The MQ + Redis interaction not only decouples components but also saves network traffic, as the pricing flow is essentially a one‑way pipeline: route planning → fare calculation → rule and inventory matching → packaging. Using MQ avoids deep callback chains, allowing downstream systems to listen for pricing results directly.
The next article will analyze the design and optimization of a specific pricing engine in detail.
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.