The Problem That Built an Industry

The Problem That Built an Industry

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

In December 2025, someone at Technogise opened MakeMyTrip's corporate platform, typed in a destination, and booked me two flights to London. The whole thing took under a minute. A confirmation email landed in my inbox. Six-character booking references appeared: DDTCIV and DHB4AL.

I was going to speak at ContainerDays 2026. A conference about containers, orchestration, and cloud-native infrastructure — the kind of modern, ephemeral, stateless systems I spend my working life thinking about.

The irony only hit me on the flight over.

The infrastructure that booked those flights was designed in 1960. It runs on an operating system that predates Unix. It speaks a command language built for teletypes. It has been running continuously, without a full rewrite, for over six decades — and it handles roughly 10,000 transactions per second at peak.

I build distributed systems. I thought I understood complex infrastructure. Then I looked at my own boarding pass and pulled the thread.

This is a six-part series about what I found.

The World Before SABRE

To understand why this infrastructure exists, you need to understand the problem it was built to solve.

By the mid-1950s, American Airlines was managing reservations on index cards. A booking required a phone call to an agent, who would search physical card racks across multiple city offices, confirm availability verbally, and call the passenger back. A transatlantic reservation could take 90 minutes to confirm. The airline was processing roughly 85,000 reservation requests a day across 50-plus cities. The system was collapsing.

The origin of what would become the GDS — Global Distribution System — is almost mythological. In 1953, C.R. Smith, president of American Airlines, was seated next to R. Blair Smith, an IBM salesman, on a cross-country flight. By the time they landed, the outline of a solution had been sketched. IBM and American Airlines entered a formal development partnership in 1959.

The result was SABRE — Semi-Automated Business Research Environment. It went live in 1964.

The same year the IBM System/360 was announced. Three years before the first ATM. Five years before the moon landing. Fifteen years before the first VisiCalc spreadsheet.

Within a decade, every major airline followed suit:

| GDS | Founded | Original Owner | Tech Foundation | |---|---|---|---| | SABRE | 1964 | American Airlines + IBM | IBM ACP / TPF | | Apollo | 1971 | United Airlines | IBM TPF | | Galileo | 1987 | United + BA + KLM + Swissair | IBM TPF | | Worldspan | 1990 | Delta + Northwest + TWA | IBM TPF | | Amadeus | 1987 | Air France + Lufthansa + Iberia + SAS | Bull mainframe → Unix |

Notice the common thread. They all converged on the same underlying runtime. Which brings me to the piece of technology that most software engineers have never heard of, and which is almost certainly processing a flight booking somewhere in the world as you read this.

TPF — The OS That Refuses to Die

Transaction Processing Facility (TPF) is an IBM mainframe operating system descended from ACP, American Airlines' original Airline Control Program. It was designed for one purpose: processing enormous volumes of simple transactions with sub-millisecond response times.

It is not Unix. It does not share Unix's lineage, its philosophy, or its abstractions. It predates Unix by a decade.

Understanding TPF requires setting aside almost everything you know about modern operating systems:

| Property | TPF | Modern OS | |---|---|---| | Process model | No processes. No threads. Short-lived "programs" that execute and exit. | Processes, threads, coroutines | | Memory model | Fixed memory "cells" per transaction. No heap. No dynamic allocation. | Virtual memory, heap, GC | | I/O model | Extremely fast synchronous I/O to DASD (Direct Access Storage) | Async I/O, block storage, NVMe | | Scheduling | Preemptive, priority-based, microsecond granularity | Typically millisecond granularity | | Failure model | Transaction-level rollback. The system does not crash — the transaction does. | Depends on application | | Primary language | Assembler. C was added later. | Everything |

The key insight is that TPF is not really an OS in the way you think of one. It's closer to what we would now call a transaction runtime — a system purpose-built to receive a unit of work, execute a short program against it, commit state changes, and immediately move on. No daemons. No background threads. No connection state persisted in memory between transactions.

This design was made for one workload. It is exceptionally good at that workload.

Modern TPF-based systems handle around 10,000 transactions per second under normal conditions. During a fare sale — when millions of customers simultaneously discover that flights are cheap — that number can reach 50,000 TPS. End-to-end message round-trip: roughly 100 milliseconds.

In the 1990s, when every other industry was migrating off mainframes to Unix, airlines looked at the performance numbers and stayed put. The replacements couldn't match the throughput. Many still can't. The IBM Z-series mainframes running z/TPF today are not running it out of nostalgia. They are running it because nothing else has beaten it for this specific job in 60 years.

There is a lesson in that. I will come back to it.

Where My Flights Fit Into This

When Technogise booked my ContainerDays travel through myBiz, the booking touched a specific layer of this ecosystem. MakeMyTrip uses Amadeus as its GDS — the system born from a 1987 partnership between Air France, Lufthansa, Iberia, and SAS, and now the dominant GDS across Europe, India, and much of Asia-Pacific.

Amadeus is not running on the original 1987 Bull mainframe. It migrated to Unix in the 1990s, and has since moved progressively toward a more modern architecture. But the data model, the protocol, and crucially the command language that agents use — cryptic mode — remain continuous with the original 1960s design. The format of my PNR, the structure of my e-ticket, the way the fare is calculated: all of it follows conventions established before I was born.

My return flights had a further complication. The outbound was entirely Air India — DDTCIV, NAG→DEL→LHR. Air India runs on Amadeus Altéa, a modern PSS (Passenger Service System) built on top of the Amadeus infrastructure. They migrated to it in 2023, replacing a legacy SITA system in one of the largest airline PSS migrations in Asian aviation history.

The return — DHB4AL, MAN→LHR→DEL→NAG — mixed British Airways (who also runs on Amadeus Altéa) and Air India. One PNR, two airlines, the same underlying platform. That consistency is what made the booking work. It is also what made the re-accommodation work when things went wrong — and things did go wrong.

But I am getting ahead of myself.

IndiGo and the Budget Carrier Divergence

There is another major Indian airline worth understanding before we go further: IndiGo.

IndiGo — the largest airline in India by market share — does not use Amadeus. It uses Navitaire, a PSS built specifically for low-cost carriers, now owned by Amadeus but operated as a separate product. Navitaire's NewSkies platform is purpose-built for high-volume, low-margin, point-to-point flying — no interline, no complex fare construction, no legacy baggage.

This is a deliberate architectural choice. Navitaire is cheaper to operate, faster to configure, and optimised for the IndiGo model: high frequency, fixed pricing, minimal complexity. The trade-off is reduced interoperability. IndiGo distributes inventory into Amadeus for travel agent bookings — you can see 6E flights in a cryptic availability display — but the ticketing and check-in systems are entirely Navitaire.

The split matters when something goes wrong.