Uber's system design

0/4
☰
Uber · system design

Uber is a live map of every driver plus a matchmaker: phones stream their position in, a dispatch system picks the best car for a batch of riders, and every trip is a state machine that must never be half-changed.

+ The whole system in one paragraph

Uber is a loop between phones and servers. Every online driver's phone streams its GPS position into an index that files drivers by map cell. When you request a ride, Uber reads only the cells near you, ranks those drivers by drive time and offers the trip to the best one. Then it pushes every change to both phones.

40M+
trips a day — rides and deliveries (Q4 2025)[1]
208M
monthly active consumers (Q2 2026)[2]
3.9B
trips in one quarter (Q2 2026)[2]

In this lesson

4 chapters · ~7 min · a quick check in each

Everything is on this page — just scroll down ↓

Chapter 1 of 4

The whole system

1
Requirements

What it must do — and how well

The job, before any boxes. Yellow notes are what Uber must do for riders and drivers; blue notes say how well. Every box later exists to meet one of these.

ⓘ Details & sources

Yellow = what the system must do. Blue = how well it must do it.[1][5][9][14]

Open the app: showthe cars around youand a price.Match you with agood driver withinseconds.Show your car comingtoward you, live.Never lose orhalf-change a trip;pay everyone right.Every onlinedriver's GPS, every4 s (2015).40M+ trips a day (Q42025).99.99% available, nodata loss (2021goal).An ETA in a fewmilliseconds.
2
Architecture

Uber in one picture

Requests go in through the API gateway; updates come back to phones through the push platform. The marketplace picks your driver. One database holds each live trip, another keeps history.

ⓘ Details & sources

The driver's arrow carries GPS and the trip's taps (accept, start, end). Tap any piece; play a flow.[9][8][16][6]

Watch it happen:
Marketplace — who picks you uprequest2GPS1live map5offer5driver positions1quote2new trip3per hexagon2every change3match4who's near?4ETAs4updates5trip done6trip history6API gatewayone door for every appRider apprequest & trackDriver appGPS every 4 sPush platformRAMEN: offers, mapPricingsurge per hexagonFulfillmenttrip state machinesCloud SpannerACID transactionsLocation indexdrivers by map cellETArouting + DeepETADispatchbatched matchingDocstorebuilt on MySQLPaymentszero-sum money orders
clientedge / CDNload balancerservicecachedatabase dashed border = simplified model
123456
Step 1 of 6

All the time, every online driver's app sends its GPS position through the API gateway into the location index — every four seconds, per Uber in 2015.

3
Sequence

Request a ride, second by second

The one request everyone makes, in time order. The server pushes what changed instead of the apps asking — that's why your map moves without a refresh.

ⓘ Details & sources

Simplified from Uber's own posts. App calls go through the API gateway (not drawn); dispatch's offer and fulfillment's updates both reach phones through the push platform (the next diagram, under 'Go deeper').[5][8][9][17][19]

Driver appDispatch1. GPS ping, every 4 s (2015)Rider appFulfillment2. Request a rideFulfillmentDispatch3. Find a driverDispatch4. Nearby cells + ETAs, match the batchDispatchPush platform5. Offer for the best driverPush platformDriver app6. Offer cardDriver appFulfillment7. AcceptFulfillmentPush platform8. Trip acceptedPush platformRider app9. Driver, car, pickup time

9 steps. Follow the flow one step at a time — what happens first, and what comes next.

Curious? Go deeper+ 2 optional
4
Sequence

How a push finds your phone (RAMEN)

Uber keeps one open connection to every app and pushes changes down it, numbered, so nothing is lost if you reconnect. That's why your map moves by itself.

ⓘ Details & sources

It carries offers, pickup and arrival times, route lines and nearby cars. Dec 2020: 1.5M+ open connections, 250,000+ messages a second, 99.99% server-side reliability.[8]

Your appRAMEN server1. Open the stream (seq 0)MarketplaceFireball2. A driver acceptedFireballAPI gateway3. Push API + device contextAPI gatewayRAMEN server4. Message for this userRAMEN server5. Route to the server holding youRAMEN serverYour app6. seq 3: driver on the wayYour appRAMEN server7. Reconnect: last seen seq 2RAMEN serverYour app8. Resend from seq 3

8 steps. Follow the flow one step at a time — what happens first, and what comes next.

5
State machine

A trip's life, as Uber's API reports it

Every trip is a state machine: one state at a time, moving only along the arrows, so rider, driver and servers can change it at once without leaving it half-changed.

ⓘ Details & sources

The public statuses in Uber's developer docs. Inside, since 2021, each entity is a statechart (a state machine with nested states) and every move is a transaction.[19][9]

a driver says yesnear the pickupyou get indrop-offProcessingfinding a driver (or: no driversavailable)1Accepteddriver on the way to you2Arrivingat the pickup, or about to be3In progresspickup → destination4Completedthen the money moves5

5 steps. Follow the flow one step at a time — what happens first, and what comes next.

Quick check

Uber carries 40M+ trips a day. Roughly how many trips is that per second?

Pick one — or just keep scrolling, it's not graded.

Keep going — it's free

Create your free account to unlock the rest of Uber's system design, keep your progress and pick up right where you left off.

  1. 2Matching & pricing
  2. 3Maps & ETAs
  3. 4Failures & growth
Create my free account →I already have one — log in
Questions & comments

Ask anything about this system, or share how you'd design it.

Log in to join the conversation