Scaling Uber with Thuan Pham (Uber's first CTO)
When Thuan Pham joined Uber in 2013, the company had 40 engineers, did 30,000 rides per day, and the system crashed multiple times per week. He had five months before the dispatch system would hit an irreversible brick wall. Seven years later, he left as CTO of one of the most complex engineering organizations ever built — a company with 5,000 microservices, hundreds of internal tools, and a footprint spanning the globe. How do you scale through that kind of chaos? How do you decide what to rewrite, what to buy, what to build from scratch when the runway is measured in weeks, not quarters? And what happens when your CEO tells you: «We're launching in China. You have two months.»
Kernaussagen
Uber rewrote its dispatch system in four months because the existing architecture would have hit capacity in October — and it was May. The only requirements: a city must run on multiple boxes, and a box must power multiple cities.
Uber ended up with thousands of microservices not by design, but because teams were told: anything new must be built outside the monolith. Meanwhile, a decomposition team spent two years trying to pull the monolith apart — but the business was growing so fast that other teams added to it faster than it could be dismantled.
Launching Uber in China was estimated at 18 months by industry peers. Thuan's team scoped six months. Travis wanted two. They shipped in five — starting with the biggest city first, which created unstoppable momentum for the rollout.
Uber built hundreds of internal tools (Jaeger, Schemaless, M3) because existing open-source solutions broke at Uber's scale. When Postgres randomly failed and no one could diagnose it, Thuan realized: if you depend on someone else and they can't help, you're terrified.
The traits that made engineers great before AI — curiosity, fearlessness, willingness to break new ground — are the same traits that make engineers great with AI. Complacency is death. The best engineers are already 2–3x more productive with AI than average engineers.
Kurzgesagt
Uber's legendary engineering complexity wasn't a plan — it was the result of surviving violent, unrelenting growth where every architectural decision was made under existential time pressure, and the only rule was: don't let anyone block anyone else.
The 30-Hour Interview That Defined Uber's Engineering Culture
Travis Kalanick interviewed Thuan for over 30 hours across two weeks, whiteboarding everything from code quality to firing philosophy.
When Thuan met Travis in 2013, the interview wasn't a typical executive vetting process. Travis committed over 30 hours across two weeks, meeting daily for 2-hour sessions — often via Skype as he traveled between regional offices. On day one, Travis filled a whiteboard with topics: general leadership questions (hiring, firing, communication), engineering specifics (code quality, QA, design), and a short list of five cultural principles he wanted in his engineering team. Thuan took a photo of that whiteboard; he still has it on his phone.
Travis once stopped mid-conversation to call his EA and move his flight so they could keep talking. The process wasn't just an interview — it was a simulation of what working together would actually feel like. Could they disagree and work it out? Did they share core principles? The level of passion and commitment Travis showed was magnetic. Thuan realized he wasn't being vetted for a role; he was being invited into a partnership. The intensity was a preview of what Uber would demand — and what it would give back.
Rewriting Dispatch Before the Brick Wall
Uber's dispatch system would hit capacity in October; Thuan gave the team two requirements and four months to survive.
Identify the runway Thuan asked leading questions: What happens when the city gets larger? What's the biggest box you can use? The team realized New York City would exceed capacity by October. It was May.
Set minimal constraints Thuan gave the team just two requirements: a city must be powered by multiple boxes, and a box must power multiple cities. No new features. Just make it scale.
Ship before the deadline The team rewrote dispatch in a new architecture and deployed it in August–September, right before the brick wall. Uber survived to fight another day.
Repeat for the next bottleneck Database was next. Then the API monolith. The process became a pattern: identify the threat, estimate the runway, survive, then buy time to plan the next phase.
Why Uber Ended Up With 5,000 Microservices
Microservices weren't a grand architecture plan — they were survival tactics under violent growth pressure.
Uber's microservices architecture emerged from a simple rule: anything new must be built outside the monolith. Meanwhile, a dedicated team worked to decompose the API monolith — a task that in isolation would have taken 3 to 6 months. But the business was growing so fast that other teams kept adding to the monolith faster than the decomposition team could pull things out. The codebase ballooned before it shrank. The process took two years.
The philosophy was: no one should block anyone else. Teams needed to ship features to survive the growth, so if a piece of functionality hadn't been extracted yet, they added it to the monolith. Eventually, the monolith was fully decomposed, but by then Uber had thousands of microservices. None of this was planned. It was the architectural consequence of hockey-stick growth layered on top of hockey-stick growth. Later, after the chaos stabilized, Uber launched Project ARC to consolidate and clean up — introducing domain interfaces over clusters of related services. By 2026, Uber had fewer microservices than in 2016.
Launching China in Five Months: The Hardest Thing First
Building Internal Tools Because Open Source Couldn't Scale
Uber built Jaeger, Schemaless, M3, and hundreds of other tools because existing solutions broke at Uber's scale.
Thuan remembers a terrifying moment early on: Postgres would randomly fail, taking services down without explanation. He went on LinkedIn begging anyone with Postgres kernel knowledge to consult. They spent weeks diagnosing the issue. The terror wasn't the technical problem — it was the dependence. There was no single company to call, no one to pay for an answer. That experience shaped a principle: if you can't control it and no one can help you, you're vulnerable.
Uber started building its own data layers. Schemaless used MySQL as a table store, but all logic lived in application code Uber controlled. M3 was built because the monitoring tools they used hit capacity during the 2015 holiday season — receipts didn't arrive for two days. By 2016, Uber had built Jaeger for distributed tracing, RingPop for service coordination, TChannel for RPC, and hundreds of other internal tools. Not every tool was absolutely necessary, Thuan admits — but the critical ones were. Uber's scale in 2013–2016 broke every open-source solution available at the time. They had no choice but to build.
The L5A/L5B Decision: Breaking Senior Into Two Levels
Thuan split Uber's senior engineer level in two to give people a sense of progress during a five-year journey.
The L5A/L5B Decision: Breaking Senior Into Two Levels
Thuan realized the journey from mid-level engineer to staff engineer could take five years. Many engineers would plateau before reaching staff. To give people a sense of progress and recognition, he split the senior level into L5A and L5B (Senior I and Senior II). It was controversial — and after he left, Uber inflated the levels, pushing L5B to staff. But Thuan stands by the decision: it acknowledged reality and gave engineers milestones during a long climb.
What Makes a Great Engineer in the Age of AI
The best engineers are already 2–3x more productive with AI than average engineers — curiosity and fearlessness still separate the great from the good.
The Three Tours of Duty: Purpose Over Comfort
Thuan stayed at Uber through three distinct phases, each time asking: Am I still needed here?
Tour One: Fix the Broken Stuff (2013–2015) Make things work. Make them reliable. Survive the scale. Rewrite dispatch, rebuild infrastructure, stop the crashes.
Tour Two: Scale Worldwide (2015–2017) Launch China. Build the platform for global scale. Support explosive growth in every dimension. Build the tools no one else had built.
Tour Three: Get Through the Storm (2017–2020) After Travis stepped down and Uber faced a turbulent year, Thuan re-upped for a third tour. His purpose: help the company survive until a new CEO arrived and stabilized the org. He stayed through the IPO and into 2020.
How Reputation Compounds Quietly Over Decades
Thuan never had a job search process — people came to him because of relationships built over 20 years.
“If you try to do a really good job at every company you've been working well with all the people that you work with, including your own team, your peer, whatever it is. Over time, very slowly, you accumulate a decent reputation in people's mind. And people always come and go throughout the industry. But if you're good with them, to them, whatever, they tend to remember that. And then when you become available, then people come to you.”
Personen
Glossar
Haftungsausschluss: Dies ist eine KI-generierte Zusammenfassung eines YouTube-Videos für Bildungs- und Referenzzwecke. Sie stellt keine Anlage-, Finanz- oder Rechtsberatung dar. Überprüfen Sie Informationen immer anhand der Originalquellen, bevor Sie Entscheidungen treffen. TubeReads ist nicht mit dem Content-Ersteller verbunden.