Loading…

Understanding the problem

About a million drivers’ phones report their position every few seconds, and about a thousand riders a second ask for a car. Each request needs the best free driver nearby within seconds, an offer the driver can accept or ignore, and a trip followed to the charge. The hard parts are the search, never giving one driver two trips, phones that go quiet, a stadium emptying at once and a region going dark.

The practice brief sets the scope below. Settle early how long a driver has to answer, whether a trip is offered to one driver at a time, and what a region outage may cost.

Functional requirements

CoreDrivers go online and offline in the driver app; while online, the app sends the phone’s position every 4 seconds.
CoreA rider sets a pickup and a destination, sees a price and an estimated pickup time, and requests a ride. Prices may rise in an area while riders there outnumber drivers.
CoreEach request is offered to a nearby available driver, who has 15 seconds to accept or decline it.
CoreOnce a driver accepts, the rider sees the driver’s position on a map until pickup; the driver marks arrival, starts the trip and ends it at drop-off. Either side can cancel before pickup.
CoreWhen the trip ends, the rider’s saved card is charged the quoted price through the existing payments service.
Below the linePooled rides, where riders share a car.
Below the lineRides booked in advance.
Below the lineRatings and tips.
Below the lineEmailed receipts.
Below the lineChat between rider and driver.It rides on the same connections and adds nothing to dispatch.

Non-functional requirements

ConsistencyA driver is never on two trips at once, and a trip never has two drivers.
LatencyMost riders see a driver accept within about 30 seconds of requesting; finding candidate drivers takes well under a second.
LatencyThe rider’s map shows the driver’s position no more than a few seconds old.
ConsistencyDrivers who close the app or lose signal are not offered trips.
DurabilityTrips in progress, and what riders are charged, are never lost.
AvailabilityA problem in one city or region doesn’t stop ride requests elsewhere, and a region going down stops requests in its cities for minutes at most.

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 1 million drivers online at the busiest hour worldwide; the busiest city has about 60,000.
ScaleAbout 20 million trips a day, and about 1,000 ride requests a second at the global peak.
ScaleAbout 300 cities, served from six regions: two in each of the Americas, Europe and Asia-Pacific.
ScaleAfter a big concert, about 8,000 ride requests arrive within 20 minutes from around one stadium, with about 1,000 drivers nearby.

Out of scope

Out of scopeMaps, routing and turn-by-turn navigation: the maps service returns road ETAs and routes.
Out of scopeThe payments service’s internals, and paying drivers.
Out of scopeDriver sign-up, documents and ratings.
Out of scopeFraud and safety checks.
Out of scopeHow prices, and their rises in busy areas, are calculated.

Check yourself

Why ask how long a driver has to answer?
Show answerHide answer
It bounds how long a phone that never answers can tie up a trip and a driver, and it sets the worst wait before the next driver is asked.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Start from drivers online and how often each phone reports, then compare with the trips: positions are the write load, and they fit in memory.

Back of the envelope from the brief

Quantity	Value	Working
Position updates	About 250,000 a second	1 million drivers online, each every 4 seconds.
Busiest city	About 15,000 a second	60,000 drivers every 4 seconds: what one city’s servers take.
Ride requests	About 1,000 a second at peak	From the brief, with 20 million trips a day.
Trip and offer writes	About 8,000 a second	About 8 offers and status changes per request.
Current positions	About 100 MB	1 million drivers × about 100 bytes.
Stadium exit	About 8 riders per nearby driver	8,000 requests in 20 minutes, about 1,000 drivers nearby.

Architecture diagramWhat the peak asks of the design

Illustrative figures from the brief: position updates are about 30 times the trip writes, and they fit in memory.

Diagram as text

Components: Drivers online (Client); Location service (Service); Busiest city (Client); That city’s servers (Service); Ride requests (Client); Trip store (SQL DB). Connections: Drivers online → Location service (about 250,000 updates a second); Busiest city → That city’s servers (about 15,000 updates a second); Ride requests → Trip store (about 8,000 writes a second).

Read:Learn: Numbers and capacity estimation

Try it: The numbers that shape the designGuided practice · Ride dispatch, Ride-hailing app · Senior

Check yourself

Which number decides where positions live?
Show answerHide answer
About 250,000 position writes a second, roughly 30 times the trip writes. The durable, transactional store for trips shouldn’t take them.

Core entities

Positions and trips live apart: one entry per online driver, overwritten every few seconds and allowed to lose seconds, against trips that change a handful of times and must not be lost. A position carries the app’s own sequence number, so a delayed update can’t move a driver backwards. Offers are records of their own, so each answer refers to exactly one offer.

The records that matter

Entity	Key fields	Why it exists
Driver	`driver_id`, city, vehicle, status (offline, available, offered, on trip)	The status is what a claim checks.
Driver position	`driver_id`, lat, lng, heading, `seq`, `received_at`	One per online driver, in memory.
Trip	`trip_id`, rider, driver, city, pickup, destination, quoted price, status, `request_id`, version	Every change is a guarded move between statuses.
Offer	`offer_id`, trip, driver, sent at, deadline, answer	One per driver asked.
Payment	`trip_id`, amount, status	Owned by the payments service.

Architecture diagramThe life of a trip

Read:Learn: Data model design Learn: Storage choice justification

Try it: Drivers, riders and the life of a tripGuided practice · Ride dispatch, Ride-hailing app · Senior

Keep reading+1 min

A store for each

Positions in Redis per city, or a log feeding the matchers’ memory, or a write-optimised store with a short lifetime per row. Trips, offers and quotes in PostgreSQL with synchronous copies. Sending every position write through the trip database would slow the part that must not be lost.

Check yourself

Why keep offers as records of their own rather than a field on the trip?
Show answerHide answer

The API

Actions are a handful of calls. Both apps keep a WebSocket open while in the foreground: positions go up, offers and trip changes come down.

A compact contract

Call	Request	Response	Notes
`POST /v1/quotes`	pickup, destination, product	`{quote_id, price, pickup_eta}`	Rider app.
`POST /v1/trips`	`quote_id`, `request_id`	`201 {trip_id, status}`	A repeated `request_id` returns the same trip.
`WS /v1/connect`	Driver: `{lat, lng, heading, seq}`	`offer.created`, `trip.updated`, driver position	A push notification when in the background.
`POST /v1/offers/{id}/accept`	None	`200 {trip}` or `409 {reason}`	409 once the offer has ended or gone.
`POST /v1/trips/{id}/arrived`, `/start`, `/end`, `/cancel`	None	`200 {trip}` or `409`	Each needs the status before it.
`GET /v1/trips/{id}`	None	The trip now, with its version	Read first after a reconnect.

Read:Learn: API contract design Learn: Protocols and real-time transports

Try it: From request to drop-off: the APIGuided practice · Ride dispatch, Ride-hailing app · Senior

Keep reading+1 min

Why a socket for positions

A request per update costs headers and a round trip every few seconds for every phone; one open connection carries positions up and offers down. HTTPS posts over a reused connection also work.

Check yourself

A driver taps Accept on an offer that just went to someone else. What comes back?
Show answerHide answer

High-level design

Four flows carry the design: a driver’s position, a request until a driver accepts, the rider watching the car, and the end of the trip with its charge.

Positions: a firehose kept out of the trip store

Each driver app sends a small message on its socket every 4 seconds to a connection server, which hands it to the location service. That service overwrites the driver’s entry in the city’s in-memory position store, and moves free drivers between cells so the search can go straight to an area. Nothing here touches the trip database. The same stream goes to a log for history and analytics, off the matching path.

Architecture diagramPositions: a firehose kept out of the trip store

Each update overwrites one entry per driver in the city’s memory and moves a free driver between cells; the trip database doesn’t see it.

Diagram as text

Components: Free drivers by cell (Cache); Driver app (Client); Connection server (API gateway); Location service (Service); Latest position per driver (Cache); Position log (Queue); History (Object store). Connections: Driver app → Connection server (position + seq); Connection server → Location service (position); Location service → Latest position per driver (overwrite if newer); Location service → Free drivers by cell (move if free); Location service → Position log (copy), asynchronous; Position log → History (analytics), asynchronous.

Read:Learn: Write-heavy Learn: Storage choice justification

Try it: The system, end to endGuided practice · Ride dispatch, Ride-hailing app · Senior

Check yourself

The position store loses its last few seconds in a crash. What breaks?
Show answerHide answer
Very little: every online driver sends a new position within seconds, so the store refills itself. Losing a trip would be a different matter, which is why trips live elsewhere.

Requesting: from a quote to an offer

The rider gets a quote from the pricing service, the price and pickup ETA, then posts the trip with it. The trip service writes the trip as requested, the payments service authorises the card for the quoted price, and the trip goes to its city’s matcher. The matcher finds nearby free drivers, asks the maps service for road ETAs to a short list and ranks by ETA rather than straight-line distance, claims the best driver and pushes the offer over the driver’s connection. After the accept, the rider sees that driver’s position every few seconds.

Architecture diagramRequesting: from a quote to an offer

Ending the trip, and each city’s home

Ending the trip writes the completion and an outbox row in one transaction (transactional outbox (opens in a new tab)); a relay publishes “trip completed”, and the payments service captures the authorised amount once per trip id. The driver sees “trip ended” at once, and a slow card network only delays the receipt.

Each city is served by one region, where its positions, matchers and live trips run together; the busiest cities are split into areas with matchers of their own. A search stays inside its city, and a spike in one city doesn’t touch another.

Architecture diagramEnding the trip, charging once

Design Uber

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities

A store for each

The API

Why a socket for positions

High-level design

Positions: a firehose kept out of the trip store

Requesting: from a quote to an offer

Ending the trip, and each city’s home

Sign in with Google to read the rest

Practise this

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities

A store for each

04The API

Why a socket for positions

05High-level design

Positions: a firehose kept out of the trip store

Requesting: from a quote to an offer

Ending the trip, and each city’s home

Sign in with Google to read the rest

12Practise this

Understanding the problem

The numbers that shape the design

Core entities

The API

High-level design

Practise this