What a travel booking engine actually has to handle
Search that feels instant, over suppliers that aren't. Prices that change mid-booking. Money moving in three directions.
Trillune Engineering7 min read
From the traveller's side, a booking engine is a search box and a results list. Underneath, it's one of the more demanding kinds of software a business can run: volatile inventory, many suppliers with different formats, and financial obligations that start the moment a seat is held.
Supply is fragmented
Flight content may come from GDS connections, direct airline APIs including NDC-based offers, and aggregators; hotels from bed banks, channel managers and direct contracts. Each has its own data model, error behaviour and performance profile. The first job of a booking platform is normalization: turning many formats into one internal model the rest of the system can trust.
Search has to be fast when suppliers aren't
- Query suppliers in parallel with individual timeouts
- Stream partial results rather than waiting for the slowest
- Cache where fares allow it — and re-price before booking
- Deduplicate the same product offered through different channels
Price is a pipeline, not a number
The price a customer sees is usually the supplier's net fare plus taxes, adjusted by markup rules, commissions, agent-specific pricing, promotions and currency conversion. Those rules should live in a pricing engine that business users can manage — not in code, and not in spreadsheets.
Money moves in several directions
In B2B travel, agents often book against a wallet or credit line, the platform settles with suppliers, and refunds and changes flow back. A ledger-based design — where every movement is an immutable entry — makes that traceable and reconcilable.