GDS and NDC side by side: designing a booking engine that handles both

For decades, a booking engine could treat airline content as one thing: whatever the Global Distribution System returned. IATA’s New Distribution Capability changed that. Today most serious travel platforms consume both, and the architectural question is no longer whether to support NDC but how to support it without running two booking engines under one logo.

Two channels, two mental models

GDS content is shaped around fares, availability and the passenger name record. Pricing is largely filed in advance, the PNR is the record of truth, and ticketing is a distinct step that issues an e-ticket against it.

NDC is shaped around offers and orders. The airline constructs an offer dynamically in response to a request, often bundling seats, bags and other services, and the offer expires. When it is accepted, the airline creates an order that it owns and manages. Servicing — changes, cancellations, refunds — happens against that order through the airline’s own API.

Those are not cosmetic differences. They change caching, pricing display, post-booking flows and what “the booking” even means inside your system.

Normalise the offer, not the transport

The most useful boundary is a supplier adapter layer that translates every channel into one internal offer model. Each adapter owns its protocol, authentication, message format and error vocabulary. Everything above it — search aggregation, ranking, markup, checkout — works on the normalised model.

A practical internal offer carries at least:

• a stable internal ID and the supplier’s original reference
• itinerary segments and fare or price breakdown
• included and optional services
• an explicit expiry time
• the capabilities the source supports after booking (change, cancel, refund, add service)

That last field matters more than it looks. If the UI knows up front that an order can be changed online, it can offer that path; if it cannot, the platform routes the customer to an assisted flow instead of failing at the last step.

Treat time as a first-class constraint

GDS-era platforms often cached search results generously. NDC offers are dynamic and short-lived, so aggressive caching produces prices that cannot be booked. Store the expiry with every offer, re-price before payment, and design the checkout to handle a changed price as a normal outcome rather than an exception.

Keep the order model channel-agnostic

Inside the platform, an order should look the same whether it was created through a PNR or an NDC order. Keep the supplier’s reference and channel as attributes, and push channel-specific servicing logic back into the adapters. Finance, customer service and reporting then work from one model.

Make the seams observable

With multiple suppliers, most incidents happen at the edges: timeouts, schema changes, unexpected error codes. Log each adapter call with a correlation ID, record latency per supplier and per operation, and alert on error-rate changes rather than single failures. When a carrier changes its API, you want to see it in a dashboard before customers see it at checkout.

The takeaway

Support GDS and NDC as sources, not as products. One offer model, one order model, and thin, well-instrumented adapters at the edge give a booking engine room to add or retire channels without rewriting everything in between.