Design Uber

For this problem, we'll design the core ride flow: quoting a fare, requesting a ride, matching a nearby driver, and getting the driver to the pickup and the drop-off. We'll leave ratings, scheduled rides and payments internals out. Interviewers love Uber because it packs three classic problems into one prompt: a write-heavy stream of moving points, a "who's near me" search, and a booking that must never give one driver two rides.

011. Understand the problem

Functional requirements

Here's the scope I'd agree on in the first few minutes. Users should be able to:

1. Get a fare estimate. A rider enters a pickup and a destination and sees a price and an ETA.
2. Request a ride from that estimate.
3. Be matched with a nearby available driver. The system finds one, not the rider.
4. Accept or decline as a driver, then navigate to the pickup and on to the drop-off.

Non-functional requirements

The system should:

• Match fast, or fail fast. A rider gets a driver within about 1 minute, or a clear "no drivers available". Nobody waits five minutes for a spinner.
• Be strongly consistent for matching. A driver is never offered or assigned two rides at the same time, and a ride never gets two drivers.
• Absorb spikes. When a concert ends, ~100k requests can arrive from a few blocks around one stadium in a few minutes. None of them should be dropped.
• Ingest locations with low latency. A driver's position should be searchable within a second or two of the ping, at hundreds of thousands of writes a second.

022. The set up

Plan the approach

We'll build the design one functional requirement at a time, the simplest thing that works for each, with a picture at every step. Then the non-functional requirements drive the deep dives: the location stream, the double-booking problem, the stadium spike, timeouts, push and scale. Get something working on the board first, then make it fast and correct.

Core entities

Five entities carry the whole design:

• Rider: the person who requests rides. Profile and payment method on file.
• Driver: the person who drives. Car details and a status: OFFLINE, AVAILABLE, OFFERED or ON_RIDE.
• Fare: a priced quote for one pickup and destination, with an expiry. The rider requests a ride from a fare.
• Ride: one trip from request to drop-off. Holds the fare, the assigned driver and a status that moves REQUESTED → ACCEPTED → PICKED_UP → COMPLETED (or CANCELLED).
• Location: a driver's latest latitude, longitude and timestamp. Tiny, hot and rewritten every few seconds.

API

One endpoint per functional requirement. Here's how I'd write them:

POST  /fares               { pickup, destination }   -> Fare { fareId, price, eta, expiresAt }
POST  /rides               { fareId }                -> Ride { rideId, status: "REQUESTED" }
POST  /drivers/location    { lat, lng }              -> 204 No Content
PATCH /rides/:rideId       { action: "accept" | "decline" }   -> Ride | 409 Conflict

Why these verbs? POST /fares creates a quote resource, which is why it's a POST and not a GET: the server stores it and gives it an ID. POST /rides creates the ride from that ID. Location is a fire-and-forget write, so 204 keeps the response empty. PATCH changes one field of an existing ride, and it can return 409 because another driver, or a cancel, may have got there first.

Back-of-envelope estimates

Only the numbers that change the design. All of these are assumptions to confirm, and the arithmetic is ours.

Here's the catch these numbers show. Locations are a huge write rate on tiny state; rides are a low rate that must be exactly right. Those two want different storage, and most of this design follows from keeping them apart.

033. High-level design

Let's satisfy the functional requirements one at a time. Each picture is the previous one plus a few new boxes, drawn in colour; what we already had turns gray.

1) Riders should be able to get a fare estimate

The rider types a pickup and a destination and taps "See prices". We need three things:

• Rider app: the client. It talks to us over HTTPS.
• API gateway: one front door that checks the JWT, applies rate limits and routes each call to the right service.
• Ride service: owns fares and rides. For a quote, it needs a route.
• Maps API: a third-party routing provider (Google Maps, Mapbox or an in-house engine) that returns distance and ETA.
• Ride DB: a relational database. For now it holds one table, Fare.

1. The rider app sends POST /fares with the pickup and destination to the API gateway.
2. The gateway authenticates the rider and routes the call to the Ride service.
3. The Ride service asks the Maps API for the route, distance and ETA.
4. It prices the trip (base + per km + per minute, times any surge), saves a Fare row with an expiresAt a few minutes out, and returns it to the rider.

Saving the fare is the important bit. It's what lets the next step trust the price.

2) Riders should be able to request a ride from that estimate

The rider taps "Confirm". We don't add a single service here: the Ride service already owns this. We only add a Ride table.

1. The rider app sends POST /rides with { fareId }.
2. The gateway routes it to the Ride service, with the rider ID taken from the JWT.
3. The Ride service loads the Fare and checks it belongs to this rider and hasn't expired.
4. It inserts a Ride row with status = REQUESTED and the fare's price, and returns the rideId.

Use the fareId as an idempotency key as well: if the phone retries on a flaky network, the second POST /rides finds the existing ride instead of creating a second one.

3) The system should match the ride with a nearby available driver

Now the interesting part. To find a driver near the pickup, we need to know where drivers are. We add four things:

• Driver app: sends its location every few seconds while online.
• Location service: receives those pings and keeps the latest position per driver.
• Location store: where the latest positions live, queryable by "who's near this point?". Deep dive 1 decides what this really is.
• Matching service: given a ride, finds the best available driver near the pickup.

1. Every few seconds, each driver app sends POST /drivers/location through the gateway to the Location service.
2. The Location service upserts the driver's latest position into the location store.
3. After the ride is created, the Ride service hands the rideId to the Matching service.
4. Matching asks the location store for available drivers within a few km of the pickup, ranks them (closest ETA first), and picks the best one.

4) Drivers should be able to accept or decline, then navigate

Matching has a driver in mind; now it has to ask her. We add one service:

• Notification service: sends push messages to phones through APNs (iOS) and FCM (Android).

1. Matching sends an offer for the ride to the Notification service.
2. The Notification service pushes it to the driver's phone through APNs or FCM.
3. The driver taps Accept: PATCH /rides/:id { action: "accept" } goes through the gateway to the Ride service.
4. The Ride service marks the ride ACCEPTED with this driver, and the driver ON_RIDE.
5. It tells the Notification service the ride has a driver.
6. The rider gets a "driver on the way" push.

From here the driver app shows turn-by-turn directions with the maps SDK, first to the pickup and then to the destination, and keeps sending location pings. The driver taps "Picked up" and "Dropped off", which are two more PATCH calls that move the ride's status. If the driver declines, or says nothing, Matching tries the next driver; deep dive 5 makes that robust.

This design works for a demo. Now let's break it with the non-functional requirements.

044. Deep dives

Each deep dive answers one non-functional requirement. Deep dives 1 and 2 are about location ingest, 3 is about consistency, 4 and 5 are about spikes and failures, 6 is about latency to the phone, and 7 is about scale. A senior candidate drives two or three of these unprompted and gets them right. A staff candidate also sees how they interact: the same region key shards the geo index, the queue and the ride store.

1) How do we handle frequent driver location updates and find nearby drivers fast?

Our estimate says ~400k location writes a second. Every matching request then asks "which available drivers are within 2 km of this point?". Both have to be fast, and they fight each other if they live in the wrong place.

GEOADD     drivers:nyc  -73.9857 40.7484  driver:42
GEOSEARCH  drivers:nyc  FROMLONLAT -73.9851 40.7488  BYRADIUS 2 km  ASC  COUNT 20

Here's what the H3 version of the search looks like. The rider's cell first, then the six around it, then the twelve around those.

2) How do we cut the ping load without losing accuracy?

A fixed 5 s interval for every online driver is simple, but most of those pings say nothing new. A driver parked outside a café for 20 minutes sends 240 identical pings. Meanwhile, a driver 300 m from a pickup really does need to be precise.

3) How do we make sure a driver is never offered two rides at once?

Two riders 200 m apart request at the same moment. Two matcher instances each run the nearby search, and the same driver is the best candidate for both. Without coordination, she gets two offers, accepts one, and the other rider waits 10 seconds for nothing. Or worse, both accepts are recorded.

UPDATE drivers SET status = 'OFFERED', offered_ride = :rideId
 WHERE id = :driverId AND status = 'AVAILABLE';   -- 1 row: you own her. 0 rows: next driver.

SET lock:driver:42 ride:9 NX PX 10000    -> OK   (we own the offer for 10 s)
SET lock:driver:42 ride:7 NX PX 10000    -> nil  (someone else does: try the next driver)

BEGIN;
UPDATE rides   SET status = 'ACCEPTED', driver_id = :d WHERE id = :r AND status = 'REQUESTED';
UPDATE drivers SET status = 'ON_RIDE',  ride_id   = :r WHERE id = :d AND status IN ('AVAILABLE', 'OFFERED');
-- either update touched 0 rows: ROLLBACK, return 409
COMMIT;

And here's the whole request-to-accept path that the lock sits in:

1. The rider requests; the Ride service creates the ride as REQUESTED.
2. Matching reads available drivers from the rider's cells.
3. It ranks them by ETA on the road network (a driver 300 m away across a river can be 10 minutes out).
4. It locks the best driver for 10 s and sends the offer.
5. The driver accepts.
6. The Ride service runs the conditional transaction: ride still REQUESTED, driver still free. Both change, or neither does.

4) How do we make sure no ride request is dropped at peak, or when a matcher crashes?

The concert ends and 100k requests arrive in a few minutes from the cells around one stadium. In our current design, the Ride service calls Matching directly. Matching instances fill up, calls time out, and any request that was in a crashed instance's memory is simply gone. The rider sees a spinner, then an error.

5) What happens if a driver doesn't respond to an offer?

Drivers miss offers all the time: phone in a cup holder, bad signal, just ignoring it. Each offer needs a 10 s timer, and when it fires we move to the next candidate. At ~700 rides a second, with a few offers per ride, that's thousands of live timers that must survive a matcher crash.

for driver in rankedCandidates(ride):
    if not lock(driver, ttl = 10s): continue
    sendOffer(driver, ride)
    reply = await signal("driver_reply", timeout = 10s)   # durable timer
    if reply == ACCEPT and commitRide(ride, driver): return MATCHED
return NO_DRIVER

6) How do we get updates to the rider and driver apps quickly?

During a trip, the rider's map shows the car moving. The driver's phone must ring with an offer within a second. Our design so far uses APNs and FCM for everything.

7) How do we scale to many cities and keep rides consistent?

One Redis cluster, one Kafka cluster and one ride database work for a country. Globally, a rider in Mumbai shouldn't wait on a round trip to Virginia, and one region's outage shouldn't stop rides everywhere.

055. The final design

Here's everything on one board: the high-level design plus every deep dive.

One ride, end to end:

1. The rider requests a ride with a fareId; the load balancer and API gateway route it to the Ride service.
2. The Ride service stores the ride as REQUESTED in the Spanner ride store (idempotent on fareId).
3. It writes the request to the Kafka ride queue, keyed by pickup zone.
4. The matcher that owns that zone's partition consumes it.
5. It reads available drivers from the nearby H3 cells in the Redis geo index.
6. It ranks them by ETA with the ETA service.
7. The offer workflow (Cadence) locks the best driver in Redis for 10 s.
8. The Notification service pushes the offer down the driver's open stream through the push gateway (APNs/FCM if the app is in the background).
9. The driver accepts through the API gateway; the Ride service runs the conditional transaction, and the rider is told the same way the driver was.
10. All the while, the driver's GPS flows through the push gateway to the Location service, which moves the driver between cells in the geo index.

066. What interviewers look for by level

Mid-level

• A clean API with the fare quote as a server-side resource, and identity from the JWT.
• A working high-level design that covers all four requirements.
• Knowing that "nearby" needs a geospatial index (geohash, quadtree or H3), not a plain table scan.

Senior

• Separating the location stream from ride bookings, with numbers to justify it.
• An in-memory geo index with stale-driver cleanup.
• A lock with a TTL and a conditional transaction against double offers, and why you need both.
• A durable queue for requests with commit-after-match, and push instead of polling.

Staff+

• Treating the ping rate as a design lever (adaptive intervals with a server override).
• Durable workflows for offer timers, with a clear failure story at every step.
• Geo-sharding with one consistent key, scatter-gather only at borders, and a reasoned consistency choice per data type, backed by what Uber actually did.

077. Follow-up questions

What if we offer the ride to three drivers at once?

Matching gets faster in areas where drivers often ignore offers, because you don't wait out three 10 s timers in a row. The cost is drivers seeing offers they can't win. The design already handles it: lock three drivers, and the conditional transaction lets the first accept win while the others get a "ride taken" message. I'd use it only where acceptance rates are low.

What if a Redis geo shard goes down?

The index is rebuildable state. Promote the replica; any drivers it missed re-appear with their next ping, within 5 to 30 s. During the gap, matching in that region widens its search or retries for a few seconds. That's the point of keeping rides out of Redis.

What if the driver loses signal mid-trip?

The trip keeps going. Mark the location stale after ~30 s and show the rider the last known point with a "reconnecting" note. The app buffers pings and uploads them on reconnect, so the recorded route, and the fare computed from it, stay correct.

What if the rider cancels while an offer is out?

The cancel is a PATCH that flips the ride from REQUESTED to CANCELLED with the same conditional update, and it sends a signal to the ride's workflow. If the driver accepts a moment later, the accept transaction finds the ride isn't REQUESTED and returns 409. Whoever commits first wins, and there's no third outcome.

How would you add surge pricing?

Count open requests (demand) and available drivers (supply) per H3 cell every minute from the ride and location streams, and turn the ratio into a multiplier per cell. The Fare service reads it when quoting, and the multiplier is saved on the Fare, so the rider pays what they saw even if surge changes before they confirm.

088. How to say it in the interview

When I ask this question, I'm listening for three things: do you keep the location stream away from the bookings, can you find nearby drivers without a scan, and can you explain why a driver can't get two rides.