The Revolution That's Taking Forever

Part 6 of 6 in the Iron Core series: the 60-year-old infrastructure that flies 4.5 billion people a year.

I spoke at ContainerDays 2026 about container runtimes: Linux namespaces, cgroups, the kernel primitives that make Docker and Kubernetes possible. Modern, ephemeral, stateless infrastructure. Systems designed to be replaced.

The infrastructure that got me to the stage was designed before Linux. Before Unix. Before the internet.

My ContainerDays booking, made by Technogise through myBiz, went through Amadeus. An Amadeus agent somewhere in MakeMyTrip's Ahmedabad office built my PNR in cryptic mode. The commands looked like the ones in Part 3. The data model was defined in the 1960s.

IATA has had a plan to replace this since 2012. It is called NDC. Fourteen years later, it is still incomplete.

What NDC Actually Is

NDC (New Distribution Capability) is an IATA XML standard for airline distribution. Where existing GDS distribution is built on cryptic commands, SITA Type B messages, and a data model from the teletype era, NDC is a modern API: REST-ish, XML-based, structured, and designed to allow airlines to distribute richer content directly to any technical buyer.

The problem NDC was created to solve is real. The existing GDS model constrains what airlines can sell. A GDS availability response returns fare classes and prices. It cannot easily return ancillary products at the time of shopping: specific seat upgrades, lounge passes, premium meal bundles, co-branded credit card offers. The airline's rich product catalogue is invisible to the GDS distribution channel.

NDC changes this by allowing airlines to respond to a shopping request with their full offer:

The technical specification is published and freely available. Several airlines have built NDC APIs. Several aggregators and TMCs (Travel Management Companies) have built NDC clients. The technology, in isolation, works.

The adoption is another matter.

The Economics of Resistance

To understand why NDC has been slow, you need to understand how the existing GDS model makes money.

When a travel agent books a flight through Amadeus, Sabre, or Travelport, the airline pays the GDS a segment fee: typically USD 3 to 5 per booked segment. For a NAG→DEL→LHR itinerary, that is 2 segments, roughly USD 6 to 10 per booking. Multiplied across tens of millions of segments annually, this is hundreds of millions of dollars per year from a single large airline.

The GDS also pays the travel agency a booking incentive: a per-booking fee that rewards agents for staying in the GDS ecosystem rather than booking directly with airlines.

NDC disrupts both flows. Airlines want NDC because they can eliminate the GDS segment fee and sell directly to aggregators and OTAs. Travel agents are ambivalent: NDC could mean losing booking incentives, or having to build entirely new technical integrations per airline rather than using one GDS terminal. The GDS companies are not rushing to accelerate their own displacement.

The result is a 14-year-old standard that has produced genuine technical progress and genuine commercial stalemate. The incentive structure, not the technical specification, is what is slow.

Where Indian Airlines Stand

The Indian market is pulling in two directions simultaneously.

Air India, now under Tata Group ownership and running on Amadeus Altéa, has NDC capability. The Tata transformation has included investment in distribution technology, and Air India has been building NDC APIs as part of its broader digital transformation. For large corporate accounts, Air India NDC offers richer ancillary content than GDS distribution.

And yet: my Technogise booking, made through myBiz in December 2025, went through Amadeus cryptic. Because that is where MakeMyTrip's distribution infrastructure lives. Because that is what myBiz's backend is connected to. Because the NDC path, even where it exists, is not yet the default path for mid-market corporate travel.

IndiGo, running Navitaire, has a different NDC posture. IndiGo's low-cost model aligns well with NDC's promise of direct distribution: fewer intermediaries, lower distribution costs, more control over the product. IndiGo has been more aggressive about pushing corporate direct-connect arrangements. For IndiGo, NDC does not threaten existing GDS segment fee revenue, because IndiGo already minimises GDS distribution costs in its model.

The airline with the richer product to sell via NDC (Air India: multiple cabins, meal options, codeshare, loyalty) is the one where the existing distribution infrastructure is most deeply embedded, and therefore hardest to move. The airline with the simpler product (IndiGo) is the one where moving is least disruptive.

What NDC Looks Like in Practice

For a developer used to REST APIs, NDC looks initially familiar. A shopping request:

POST /AirShopping HTTP/1.1
Content-Type: application/xml
 
<IATA_AirShoppingRQ>
  <CoreQuery>
    <OriginDestinations>
      <OriginDestination>
        <Departure>
          <AirportCode>NAG</AirportCode>
          <Date>2025-02-08</Date>
        </Departure>
        <Arrival>
          <AirportCode>DEL</AirportCode>
        </Arrival>
      </OriginDestination>
    </OriginDestinations>
  </CoreQuery>
  <Travelers>
    <Traveler>
      <AnonymousTraveler>
        <PTC>ADT</PTC>
      </AnonymousTraveler>
    </Traveler>
  </Travelers>
</IATA_AirShoppingRQ>

Compare this to the Amadeus cryptic equivalent:

AN08FEBNAGDEL

One is expressive, structured, and parseable by any modern toolchain. The other is 14 characters. The cryptic command is faster to type. The NDC request is richer in capability and easier to integrate programmatically. The right form depends on the actor: a human agent at a terminal, or a software system processing shopping requests programmatically.

The NDC response is correspondingly rich: an offer object that includes not just flights and fares, but seat maps, ancillary products, and pricing conditions. The kind of response that allows an OTA to present a genuine product comparison rather than a commoditised price list.

The Content Parity Problem

The NDC adoption argument that cuts through the commercial noise is content parity.

An airline's NDC API often contains fares and offers not available in the GDS. This is intentional: airlines use NDC to sell directly, sometimes at preferential rates. But it creates a problem for corporate travel programmes: a traveller booking through the approved corporate TMC (who uses the GDS) may not see the cheapest or most suitable fare for their trip.

Conversely, GDS-exclusive fares also exist. Some corporate negotiated rates are only filed in the GDS, not available via NDC, because the GDS is where the TMC operates.

The market is currently fragmented across three distribution channels:

For a corporate travel programme like Technogise's, booking through myBiz, the practical answer is to use the GDS and accept that some NDC content is invisible. The administrative overhead of maintaining direct NDC connections with every airline is not justified for a company of Technogise's size. This is why my booking went through Amadeus cryptic: a rational commercial decision, not a technical failure.

What the Bird Strike Revealed About System Resilience

Part 5 described how my DHB4AL booking was automatically re-accommodated after VT-AEQ was grounded. The automated re-accommodation that fired at 14:57Z, finding me alternative flights, updating my PNR, and notifying me within minutes of the cancellation, ran on Amadeus Altéa: the same platform that processes cryptic commands, built on data model conventions from the 1960s.

It worked. It worked under stress, under time pressure, for a complex multi-leg interline itinerary, in under ten minutes.

NDC does not yet have a disruption management layer that matches this. The NDC standards cover shopping, offer management, and order creation well. They cover irregular operations (IRROPs, in industry parlance) incompletely. Altéa inherits decades of operational rules and message-level practice from the GDS world. TPF-based cores carry a parallel depth of IRROPS handling. When things break, those accumulated layers know what to do more reliably than a greenfield protocol does, because the failure modes have already happened and the handling rules exist.

This is the honest case for the status quo: not that the old technology is better in any absolute sense, but that it has been tested by sixty years of failures. Most failure modes that have occurred at scale already have a handling rule somewhere in the ecosystem. NDC, however well-designed, is starting over on that accumulation. The long tail of edge cases is still being discovered. The handling rules do not all exist yet.

The View from ContainerDays

I gave my talk. I came home, eventually, via Mumbai.

On the flight back, somewhere over the Persian Gulf, I pulled up the notes I had been making across this series. The TPF architecture. The PNR data model. The cryptic commands. The bird strike. The automated re-accommodation. The agent who overrode it.

The conference I had just spoken at was full of engineers building ephemeral, stateless, cloud-native infrastructure: systems designed to be disposable, immutable, replaced without ceremony when something better comes along.

The infrastructure that moved me across 15,000 kilometres and back was none of those things. It was stateful. It was deeply mutable. It was not designed to be replaced. It was 60 years old and had touched my booking four times in a single day without losing track of who I was or where I was going.

Cloud-native infrastructure is correct for the problems it solves. The GDS infrastructure is correct for the problems it solves. Fitness for purpose is what connects them, and it has nothing to do with novelty or architectural elegance.

The GDS will eventually be replaced. The NUC will disappear. Cryptic mode will become a museum piece. NDC, or something that follows it, will become the distribution layer for commercial aviation.

Until then: the next time you see a six-character booking reference, you know what it contains, how it was built, and what it went through to get you home.

Lessons Learned

Understanding what an existing system does before replacing it is not optional. The GDS infrastructure is old, reliable, battle-hardened, and globally interoperable in ways that took decades to achieve. NDC is technically superior in several dimensions and is still incomplete in IRROPS handling fourteen years after the standard was introduced. The gap is not a reason to delay NDC indefinitely; it is a reason to scope the replacement honestly, starting with what the old system does in failure scenarios and verifying that the new system covers it.

Distribution economics shape technology adoption more than technical quality does. NDC adoption has been constrained by a commercial ecosystem with strong incentives to maintain the status quo. The GDS segment fee, the booking incentive paid to agents, and the switching costs of building per-airline integrations are the variables that explain the adoption curve. When a technically capable standard is not being adopted, the incentive structure is usually doing more explanatory work than technical deficiency.

Operational reliability in failure scenarios is accumulated over time, not designed in advance. The Altéa disruption management system is reliable at re-accommodation because it has handled disruptions millions of times, and each failure has produced a handling rule. The design can make it easy to add handling rules without breaking existing ones, but the rules themselves are accumulated. Any replacement system will spend years in the long tail of failure modes the incumbents already know how to handle.

Know which decisions to automate, which to assist, and which to leave to humans. The agent who overrode my automated re-accommodation was not working around a deficient system. She was exercising schedule knowledge and connection familiarity that the algorithm had not modelled. The architecture correctly deferred to her. Identifying the boundary between automatable decisions and decisions that require contextual human judgement is a design problem, not a staffing problem, and aviation has sixty years of evidence about where that boundary sits.

The Series in Retrospect

When Technogise booked my ContainerDays travel in December 2025, I had no idea I was about to spend months reading IATA recommended practices, decoding fare calculation strings, and extracting ADS-B telemetry from FlightRadar24 CSV exports.

The thread I pulled, starting from six characters on a confirmation email, led to:

A 1953 conversation on a plane, a 1959 partnership, and a system live in 1964
An operating system that predates Unix by a decade, still processing 10,000 transactions per second
A command language built for teletypes that is still often faster than a consumer-style GUI for trained-agent workflows
A data model that has absorbed 60 years of edge cases without losing structural coherence
A bird strike on a Boeing 787-8 Dreamliner at Heathrow Terminal 2
An Air India agent who looked at what the algorithm proposed and found something better

The infrastructure underneath your flight is not a curiosity. It is a case study in what happens when a system is built for exactly the right problem, maintained with genuine expertise, and given time to accumulate reliability.

The Iron Core is a six-part series by Ajitem Sahasrabuddhe. Ajitem is a software engineer at Technogise and spoke at ContainerDays 2026 in London.

All flight data used in this series, including the ADS-B telemetry for BA1361, AI111, and VT-AEQ, is sourced from FlightRadar24. PNR data is reconstructed from the author's own tickets. E-ticket numbers have been partially redacted.