Design ride hailing

A rider taps "Request" and within seconds one nearby driver, and only one, gets the trip. Behind that tap: hundreds of thousands of drivers reporting their position every few seconds, an index that answers "who is near this point?" instantly, and a matching step that must never give one driver two trips or one trip two drivers. It follows the interview framework phase by phase.

1. The prompt

"Design Uber: riders request a ride from where they are to a destination, see a price estimate, get matched with a nearby driver, and track the car on a map until the trip ends and payment is taken."

Two very different workloads meet here: a firehose of location updates that only need to be roughly right, and a small number of matching decisions that must be exactly right. Saying this split out loud early is the key to the design.

2. Frame the problem

3. What it must do

1. A rider can get a fare estimate and request a ride.
2. The system matches the request with a nearby available driver, who accepts or declines.
3. Rider and driver track each other live, and the trip ends with payment.

Not now:

• Ratings.
• Pooled and scheduled rides.
• Driver onboarding.
• Routing internals: we call a routing service for ETAs.

4. How well it must do it

5. Numbers that change the design

6. The nouns

• Rider.
• Driver: with a status.
• Location: the latest position; only the newest matters.
• Fare quote.
• Ride.
• Offer: a time-limited proposal to one driver.

drivers     driver_id, status (offline | available | offered | on_trip), city, vehicle
geo index   city cell → {driver_id: (lat, lng, ts)}     in memory, TTL ~30 s
fares       fare_id, rider_id, pickup, destination, price, expires_at
rides       ride_id, fare_id, rider_id, driver_id, status (requested | matched | in_progress | done | cancelled)
locks       driver:{id} → ride_id   (SET NX with a TTL)

7. The contract

POST  /v1/fares {pickup, destination}         → {fare_id, price, expires_at}
POST  /v1/rides {fare_id}                      → 202 {ride_id}   (matching starts)
POST  /v1/drivers/location {lat, lng}          (every few seconds; often over a persistent connection)
PATCH /v1/rides/{id} {action: accept|decline}  (driver)
WS    /v1/rides/{id}/stream                    → driver position, status changes

The rider or driver comes from the session token. A driver can only update their own location and respond to offers made to them.

8. First working version

A location service writing to a drivers table, a ride service, and a matcher that queries for nearby drivers.

8.1 Reporting locations

Each driver app sends its position every 4 seconds; the location service updates lat and lng on the driver's row.

8.2 Requesting and matching

The ride service saves the request; the matcher queries drivers within a bounding box of the pickup, picks the nearest by straight-line distance, and sends that driver an offer.

8.3 Tracking

The rider's app polls the ride every few seconds for the driver's position.

9. Make it hold up

9.1 Storing and querying locations fresh locations · scale

Section 13 shows how the update interval trades write load against staleness. Design D14 explores the index structures (geohash grids vs quadtrees) in depth.

9.2 Matching without double booking correct matching · fast matching

• Find candidates: available drivers in nearby cells, ranked by estimated time of arrival (from a routing service, not straight-line distance).
• Offer to one driver at a time with a timeout (say 10 s). Broadcasting to many drivers makes them compete and annoys the losers.
• Lock the driver: before offering, atomically change the driver from available to offered with a short TTL (a conditional update, or SET driver:42 ride:9 NX PX 10000 in Redis). Another rider's matcher then skips this driver. If the driver declines or the TTL expires, the lock is released and the next candidate is tried.
• Accept: a transaction moves the ride to matched and the driver to on trip, conditional on the offer still being theirs.

9.3 Not losing ride requests no lost requests

Matching is a multi-step process with timeouts that can last a minute. Run it as a durable workflow (Module 22) or from a queue: the request is written first, and if a matcher crashes, another one resumes the same ride from its saved state. Peaks are local (a concert ends, it starts raining), so partition matchers by region.

9.4 Live tracking fresh locations

Once matched, the rider's app subscribes to the trip's channel over a WebSocket (Module 19). The driver's updates already flow through the location service; for active trips they're also published to the trip channel. Apps smooth the car's movement between updates so it doesn't jump, and drivers report more often during trips than while idle.

9.5 Pricing and trip records correct matching

The fare estimate is computed when requested and stored with an expiry, so the price the rider accepted is the price charged. Surge pricing compares demand and supply per cell, computed by a stream job over requests and available drivers. Trip records, payments and receipts go in a transactional database; payments follow Design D16 (idempotency keys, a ledger).

9.6 Cities, regions and failure scale · surviving failures

• Partition everything that's local (geo index, matchers, surge) by city, so a busy city can't slow another.
• Trips near city boundaries and airport queues need explicit rules.
• If a region's geo index is lost, it rebuilds itself from the next round of driver updates within seconds; matching pauses briefly rather than failing.
• Say the consistency split explicitly: locations can be stale and lossy; assignments and payments must be strongly consistent.

9.7 The whole design after the deep dives

A request matched through the final design.

10. Interviewer follow-ups

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• An in-memory geo index (fast, lossy) for locations.
• Atomic, TTL-based claims for drivers (correct, simple).
• One offer at a time (fair to drivers, slightly slower).
• Durable matching workflows.
• Partitioning by city.
• Staleness allowed where it's harmless; strong consistency where it matters.

What we'd watch:

• Time to match p90.
• Offer acceptance rate.
• Location age.
• Geo index write rate.
• Lock contention.
• Requests left unmatched.

At 10×:

• More regional partitions.
• Batch matching.
• Adaptive update intervals.

Common mistakes:

• Locations in a disk database.
• Two-column range queries.
• Broadcasting offers.
• No atomic driver claim.
• Matching state only in memory.
• Treating locations and payments with the same consistency.

13. Try it, check yourself, read more

How often should drivers report their location? Try the numbers. Per-node throughputs are illustrative examples, not benchmarks.