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:

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:

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. An IndiGo delay affecting an Air India connection does not trigger automatic re-accommodation between systems. The human has to intervene.

What a 30-Second Booking Actually Triggers

When myBiz confirmed my booking in December 2025, the following sequence fired:

Technogise travel admin (myBiz corporate portal)
    ↓
MakeMyTrip OTA layer (availability check, pricing)
    ↓
Amadeus GDS (seat inventory, PNR creation)
    ↓
Air India Altéa PSS (segment confirmation, HK status)
    ↓
IATA BSP (Billing Settlement Plan) — payment routing
    ↓
E-ticket issued under Air India numeric code 098
    ↓
PNR DDTCIV created, stored in Amadeus
    ↓
Confirmation email → myBiz → Technogise → me

Each arrow is a system boundary. Each boundary has its own protocol, its own failure mode, and its own eventual consistency characteristics. The 30-second booking conceals a chain of synchronous and asynchronous calls across systems built in different decades by different companies in different countries.

The PNR at the end of that chain — six characters, DDTCIV — is the thread that holds it all together.

In the next part, I will decode exactly what those six characters are, what they contain, and why the fare calculation line on my e-ticket is one of the most information-dense strings in commercial aviation.

Takeaways

Fitness for purpose beats fashionable architecture. TPF is not modern. It would fail every architectural review a contemporary engineering team would apply to it. It also handles 50,000 transactions per second with sub-100ms latency on hardware that costs a fraction of an equivalent cloud footprint. It has been doing this for 60 years. The lesson is not that old software is good software — it is that the right tool for the right job, well-maintained, is very hard to beat.

Convergent evolution is real. Every major GDS independently arrived at the same underlying platform. That is not coincidence — it is the market discovering the optimal solution to a specific problem. When you see that pattern in your own domain, pay attention to it.

Migrations are expensive. Air India's move to Amadeus Altéa in 2023 was years in the making. A company the size of an airline, with decades of booking history, interline agreements, loyalty programme integrations, and airport systems dependencies, cannot simply "lift and shift." The scar tissue from that migration is still visible in the industry. I will come back to it in Part 4.

Next: Part 2 — Six Characters. What DDTCIV actually is, what it contains, and why it is less unique than you think.

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.