Es ist eine der größten Ironien der modernen Tech-Welt: Wenn Entwickler zu Konferenzen über Cloud-Native, Kubernetes und ephemere Microservices reisen, werden ihre Flüge oft von Systemen gebucht, die älter sind als Unix. Ein aktuelles Essay von Software-Engineer Ajitem Sahasrabuddhe, das auf Hacker News für Furore sorgte, zieht den Vorhang zurück über der „Iron Core“-Infrastruktur der Luftfahrt – einem System, das jährlich 4,5 Milliarden Menschen in die Luft bringt.
Ein Flugzeug-Ticket und 60 Jahre Pfadabhängigkeit
Als Sahasrabuddhe im Dezember 2025 seinen Flug zur ContainerDays 2026 in London buchte, dauerte der Vorgang unter eine Minute. Heraus kam ein klassischer sechszeichiger PNR (Passenger Name Record): DDTCIV. Doch statt in einer modernen Cloud-Architektur landete diese Buchung in einem System, dessen Design auf die 1960er Jahre zurückgeht. Die Datenmodelle, Protokolle und Transaktionssemantiken stammen aus einer Zeit vor Unix, gebaut für Fernschreiber.
Die Ursprünge dieser Systeme sind fast mythologisch: 1953 saß der Präsident von American Airlines, C.R. Smith, im Flugzeug zufällig neben einem IBM-Verkäufer. Das Ergebnis dieser Begegnung war SABRE, das 1964 live ging und den Grundstein für das heutige Global Distribution System (GDS) legte. Damals brauchte American Airlines bis zu 90 Minuten für eine transatlantische Reservierung, die über physische Karteikarten abgewickelt wurde. Das System war am Kollabieren.
TPF: Das Betriebssystem, das sich weigert zu sterben
Das technische Rückgrat dieser Buchungssysteme ist TPF (Transaction Processing Facility), ein IBM-Mainframe-Betriebssystem. Wer TPF verstehen will, muss sein Wissen über moderne Betriebssysteme vergessen. Es gibt keine Prozesse oder Threads im klassischen Sinne, keinen Heap, keine dynamische Speicherallokation und keinen Garbage Collector. Stattdessen arbeitet TPF mit fixen Speicherzellen und kurzlebigen Programmen, die eine Transaktion abarbeiten und sofort beenden.
Das klingt für moderne DevOps-Ohren wie ein Albtraum. Die Zahlen sprechen jedoch eine andere Sprache: Im Normalbetrieb verarbeitet TPF rund 10.000 Transaktionen pro Sekunde. Bei Preis-Schlachten („Fare Sales“), wenn Millionen gleichzeitig nach billigen Flügen suchen, peakt das System bei 50.000 TPS – mit einer End-to-End-Latenz von etwa 100 Millisekunden.
Als in den 1990er Jahren jeder Branchenzweig auf Unix migrierte, blieben die Airlines bei ihren Mainframes. Kein Unix-System konnte (und kann oft bis heute) diesen spezifischen Throughput bei konstanter Latenz schlagen. Die Lektion: Fitness for Purpose schlägt fashionable Architecture.
Altäa, Navitaire und die Schatten der Vergangenheit
Auch wenn der Kern antiquiert wirkt, die Oberflächen sind modern. MakeMyTrip bucht über Amadeus, ein GDS, das ursprünglich auf Bull-Mainframes lief, in den 90ern auf Unix migrierte und heute zunehmend Cloud-native APIs anbietet. Doch unter der modernen API-Hülle tickt immer noch das Herz der 1960er: Das Datenmodell, die Tarifberechnung und die Kommandozeile („Cryptic Mode“) für Agenten sind nahezu unverändert.
Interessant wird es bei Low-Cost-Carriern wie IndiGo. Sie nutzen Navitaire, ein System, das auf einfache Point-to-Point-Verbindungen ohne komplexes Interlining optimiert ist. Es ist günstiger und schneller zu konfigurieren. Der Haken? Die Interoperabilität. Wenn ein IndiGo-Flug Verspätung hat und ein Anschluss verpasst wird, greift keine automatische Umbuchung wie bei vollintegrierten Amadeus-Systemen. Hier muss der Mensch eingreifen.
Der Kern unserer Infrastruktur
Eine scheinbar simple 30-Sekunden-Buchung triggert eine Kette aus synchronen und asynchronen Calls über Systeme aus verschiedenen Jahrzehnten. Der sechszeichige PNR-Code ist der rote Faden, der dieses Chaos zusammenhält.
Sahasrabuddhes Analyse trifft den Nagel auf den Kopf: Wir moderne Ingenieure neigen dazu, Architekturen nach modischen Prinzipien zu bewerten. Ein TPF-System würde keinen zeitgenössischen Architectural Review bestehen. Doch sein transaktionsorientiertes Design, gepaart mit 60 Jahren operativem Hardening, macht es für diesen spezifischen Workload unschlagbar. Und die Flugbranche zeigt: Wenn gemeinsame Constraints (wie IATA-Standards und Interlining) dominieren, werden divergierende Systeme zu teuer. Standardisierung schlägt Einzelgängertum.
Die Lektion für die Cloud-Native-Welt? Manchmal ist der beste Code der, der bereits seit Jahrzehnten im Produktivbetrieb läuft und einfach nicht kaputtzukriegen ist.
