DevOps for Travel & Hospitality — booking systems that stay up

What regulates the infrastructure

What actually goes wrong here

• Look-to-book pressure: search volume is orders of magnitude larger than booking volume, and because GDS and supplier transactions are metered, non-converting shopping traffic, scrapers and price-comparison bots impose real per-query cost while producing no revenue.
• Fare and availability cache staleness, which surfaces as a price or seat change at the payment step, destroying conversion at the last stage of the funnel and, in aviation, creating downstream booking and ticketing failures.
• Irregular operations, where a single weather or ATC event simultaneously peaks rebooking, contact centre, notification and refund systems while the underlying operational feeds are themselves degraded, and EU261 duty-of-care obligations accrue in parallel.
• Payment authorisation failures at booking, which are unrecoverable in the moment because held inventory is released and the customer moves to another channel rather than retrying.
• External border and identity dependencies at check-in: with carrier verification against EES now mandatory, an interface failure escalates from a slow check-in to passengers who cannot lawfully be boarded.
• Card-testing and enumeration attacks against booking payment pages, which are attractive targets because travel checkouts accept many card types across many currencies.

How demand behaves

Seasonal with sharp shocks. Booking peaks cluster in the January sun-season window and ahead of school holidays, while shopping traffic vastly exceeds bookings: IATA has reported look-to-book ratios rising from hundreds to thousands with NDC, and for OTAs and metasearch commonly above 10,000 searches to one booking. Operational shocks from weather, ATC failures and strikes invert the pattern by generating a rebooking surge unrelated to demand.

Data you will be holding

Passenger name records that combine identity, itinerary, contact and payment details in one object, passport and biometric data at the border, and cardholder data bringing PCI DSS scope. PNR is separately regulated and separately retained, which means the same passenger's data lives under two different legal regimes with different deletion rules.

Architecture this pushes you toward

A read-heavy shopping tier fronts a comparatively tiny booking tier, so most infrastructure exists to serve queries that never convert, and pre-computed fare and availability caches exist mainly to keep metered supplier transactions down. NDC shifts offer construction from the GDS back to airline offer engines, which changes the caching problem because offers become dynamic and airline-specific rather than filed and static. Inventory is eventually consistent across PSS, CRS and channel managers, so overselling is a normal consequence of propagation delay rather than an exceptional bug.

Availability expectation

No regulator-set figure, and availability matters asymmetrically. The shopping tier can be degraded deliberately by serving fewer results or older cached fares without stopping sales, whereas an outage on the booking, ticketing or check-in path produces immediate lost revenue and, during disruption, statutory passenger-rights exposure.