Als Ubers erster CTO übernahm Thuan Pham 2013 ein System, das mehrfach wöchentlich ausfiel. Vierzig Entwickler hielten einen global wachsenden Fahrdienst mit einem monolithischen Back‑End am Leben. In sieben Jahren entstand daraus eine der komplexesten Service‑Landschaften der Branche. Für Architekten und Tech Leads sind die politischen und technischen Entscheidungen aus dieser Phase bis heute lehrreich.
Stabilisieren – Architektur retten, bevor sie kollabiert
Als Pham eintrat, liefen rund 30 000 Fahrten pro Tag. Der Dispatch‑Service war ein Node.js‑Monolith, single‑threaded, vertikal skaliert nach dem Motto: größere Instanz, stärkerer Prozessor. Pham ließ das Team selbst die Grenzen erkennen: Was passiert, wenn der schnellste Prozessor erreicht ist? Die Erkenntnis zwang zum Re‑Write. Die neue Version sollte zwei Anforderungen erfüllen:
- Eine City läuft auf mehreren Maschinen.
- Eine Maschine bedient mehrere Citys.
Dieses simple NxM‑Schema erlaubte horizontale Skalierung ohne Feature‑Ballast – ein Muster, das viele Teams seither internalisiert haben.
Re‑Organisation: Program‑und‑Platform Split
Noch bevor Microservices eingeführt wurden, zerlegte Pham die Organisation. Ab 100 Ingenieuren lähmte die funktionale Matrix aus Frontend, Backend und Mobile jede Initiative. Die Lösung war der Program/Platform Split:
- Program‑Teams – End‑to‑End‑Verantwortung für User‑Features.
- Platform‑Teams – gemeinsame Infrastruktur und Tooling.
Die Umstellung auf selbst‑suffiziente Teams beschleunigte Delivery, lieferte Governance und bereitete den Übergang in Microservices vor. Viele moderne Produktorganisationen kopieren dieses Muster, oft ohne seine Herkunft zu kennen.
Vom Monolithen zu 5000 Microservices
Die Zersetzung des gewachsenen API‑Monolithen („Darwin‑Projekt“) war ein klassisches Dilemma: Während ein Team entkoppelte, fügten andere Teams neue Features hinzu. Der resultierende „Code‑Bulge“ ließ die Service‑Zahl auf knapp 5000 anwachsen. Nicht aus Architektur‑Eitelkeit, sondern aus Zwang. Geschwindigkeit hatte Vorrang vor Eleganz.
Erst Jahre später, unter dem Projekt ARC, begann Uber zu konsolidieren; heute liegt die Zahl etwas darunter. Phams Fazit: Segmentiere, wenn Wachstum dich dazu zwingt – konsolidiere, sobald du Luft hast.
Build vs Buy: Warum interne Tools unvermeidlich waren
Zwischen 2013 und 2016 sprengte Uber die Grenzen damaliger Open‑Source‑Stacks. PostgreSQL konnte Transaktionsvolumen nicht mehr zuverlässig tragen. Ohne kommerziellen Support stand das Team vor Black‑Box‑Kernelfehlern.
Die Antwort war ein eigener Data‑Store (Schemaless) und ein Observability‑Stack (M3, Jaeger, Ringpop u. a.). Das Prinzip: Kontrolle zurückgewinnen, wenn Abhängigkeiten kritisch werden. Für heutige SREs bleibt das ein Lehrstück über den Zeitpunkt, interne Werkzeuge zu bauen.
Naming Matters – professionelle Reife im Engineering
Mit wachsender Komplexität tauchten Service‑Namen wie „Mustafa“ auf. In einem legendären E‑Mail‑Rant forderte Pham „professionelle Benennungen – wir sind kein Mickey‑Mouse‑Laden“.
Kulturell war das mehr als Kosmetik: eine Erinnerung, dass Systemreife auch sprachlich beginnt. Naming‑Disziplin ist ein billiger Hebel, um Onboarding‑Kosten zu senken.
Talent Dichte und globale Recruiting‑Strategie
Ein Kernmotiv Phams bleibt Talent Density. A‑Teams stellen A‑Player ein. Um Wachstum zu halten, eröffnete Uber neun Engineering‑Zentren weltweit. Das kleine Kopenhagener Team baute Schlüssel‑Services wie den Trip‑Datastore.
Das Prinzip: bring the problem to the talent, nicht umgekehrt. Wer weltweit arbeitet, sollte Ownership gleich verteilen – nicht nur Kosten.
Die „Tours of Duty“ – drei Phasen einer CTO‑Rolle
Pham sieht seine Zeit bei Uber in drei Einsätzen:
- Stabilisieren: Ausfälle eliminieren, Architektur retten.
- Skalieren: Global exekutieren, China‑Launch in fünf Monaten.
- Konsolidieren: Organisation durch Krisen führen und Übergabe vorbereiten.
Diese Phasendenke – Intentional Engineering Leadership – hilft CTOs, den eigenen Beitrag realistisch zu bewerten und rechtzeitig den Staff weiterzugeben.
Von Uber zu Faire: AI als neue Infrastruktur‑Schicht
Heute leitet Pham die Technik bei Faire, einem B2B‑Marktplatz für Retail Brands. Seine Teams nutzen AI sowohl im Produkt (Suche und Empfehlung) wie in der Software‑Entwicklung. Mit „Swarm Coding“ orchestrieren mehrere Agenten parallel Codeänderungen; Top‑Ingenieure verdoppeln ihre Output‑Rate. Die größte Schwierigkeit liegt nicht in Greenfield‑Generierung, sondern im Bauen auf Legacy‑Code – eine Einsicht, die jede große Organisation teilt.
Pham betont:
„KI hebt den Boden, nicht die Decke. “
Die Determinanten bleiben die gleichen: Neugier, Furchtlosigkeit, Bereitschaft zum Lernen. Werkzeuge ändern sich, Haltung nicht.
Fazit: Engineering führt, wenn es vorhersieht
Für CTOs und Systemarchitekten fasst Pham’s Ansatz zwei Pflichten zusammen: Organisation bauen und um Ecken sehen. Das Team bewältigt die Sechs‑Monats‑Probleme; die Führung plant die nächsten zwei Jahre. Ubers Lehren aus der Monolith‑Krise – klare Ownership, bewusste Komplexität und strukturiertes Refactoring – bleiben relevant für jede Infrastruktur, die heute mit KI‑getriebenem Wachstum konfrontiert ist.