Design Uber

Design a ride-hailing service like Uber: riders request a ride, nearby drivers are matched, and both see each other's location in real time until the trip ends.

1. Clarify the requirements

Before drawing anything, ask questions. These are the answers an interviewer would typically give:

How many users?

10 million rides a day; 1 million active drivers at peak.

How often do drivers send location?

Every 4 seconds while online.

Which features?

Request a ride, match with a nearby driver, live tracking, trip completion and payment. Pricing models, pooling and food delivery are out of scope.

Matching latency?

A rider should be matched within a few seconds.

Consistency?

A driver must never be assigned to two riders at once.

2. Estimate the scale

Assumptions: 1M drivers online at peak, each sending a location update every 4 seconds. 10M rides per day.

• Location updates per second (peak): about 250K updates/s1M drivers ÷ 4 s = 250K updates/s.
• Ride requests per second (average): about 116 rides/s10M ÷ 86,400 ≈ 116 rides/s.

3. The high-level design

1. Apps reach an API gatewayRider and driver apps talk to an API gateway that authenticates, rate limits and routes to the right service.
2. Drivers stream their locationEvery few seconds each driver sends a GPS update. Only the latest position matters, so it goes to an in-memory geo index, sharded by region.
3. Match riders with driversThe matching service reads nearby cells, ranks drivers by ETA and offers the trip, reserving the driver atomically so two riders can't get the same car.
4. Trips are durableEach trip is a state machine (requested → accepted → started → completed) stored in a replicated database.
5. Charge after the rideWhen a trip completes, an event triggers billing workers that charge through a payment provider, with retries and idempotency keys.
6. Watch it in productionMetrics and alerts close the loop: location ingest lag, match latency and dispatch success rate.

4. The components and what each one does

API gateway API gateway

Auth, rate limits, routing. Driver apps keep a WebSocket for location updates.

Location service Service

Receives driver GPS updates every 4 s. Stateless: scales out horizontally.

Driver locations (geo index) NoSQL / KV store · Redis GEO

Latest location per driver, indexed by geohash cell; sharded by region; in memory.

Matching service Service

Find nearby drivers (geohash cells around the rider), rank by ETA, dispatch with an atomic reserve.

Nearby cache Cache

Hot cells and driver status (free/busy).

Trip service Service

Trip state machine and history. Stateless; scales out horizontally.

Trips SQL database

Trip records; sharded by city; replicas with failover.

Billing workers Workers

Charge with an idempotency key; retry with backoff.

Payment provider 3rd-party service

Stripe / Braintree.

Metrics & alerts Metrics & alerts

Dashboards and alerts on p99 latency, error rate, queue depth and cache hit ratio, so a bottleneck shows up before it becomes an outage.

5. Deep dive: geospatial matching & live location

How do you find nearby available drivers quickly, ingest 250K location updates a second, and make sure a driver isn't double-booked?

• Index driver locations with a geospatial structure: geohash / quadtree / S2 cells, kept in memory.
• Location updates are high-volume and ephemeral: write to an in-memory store, not the main DB.
• Use a lock or atomic state change (available → reserved) when offering a ride to a driver.

6. What interviewers listen for

• Ride and location APIsRider: request/cancel ride; driver: send location, accept trip.
• Trip/driver data modelTrips move through states: requested → matched → in progress → completed.
• Geospatial index (geohash / quadtree / S2)Scanning all drivers is impossible; a spatial index finds nearby ones in milliseconds.
• Real-time updates to rider and driver (WebSocket/push)Live tracking needs a server-push channel.
• No double assignment (lock / atomic state change)Two matchers might offer the same driver; an atomic state change prevents double-booking.
• Database replication and failoverA single database is a single point of failure. Replicas give redundancy and read capacity; failover promotes a replica when the primary dies.
• Partition (shard) data as it growsOne machine eventually can't hold the data or the write load. Say how you'd split it and by which key.

7. Follow-up questions

1. A concert ends and 50,000 people request rides from the same few blocks. What breaks?
2. A driver's phone loses signal mid-trip. How does your system handle it?
3. Two matching servers offer the same driver to two riders at the same moment. How do you prevent a double assignment?

The design in a nutshell

• Driver apps stream locations (every 4 s) to a location service over persistent connections; latest positions in an in-memory geo index (geohash/S2 cells, sharded by region).
• Rider requests → matching service queries nearby cells, ranks drivers by ETA, offers the trip with an atomic reserve on driver status.
• Trip service persists state transitions in a replicated DB; real-time updates via WebSocket/push.
• Payments via a provider on completion; monitoring match latency and location ingest lag.

Related lessons: The hash ring · Polling vs long polling vs WebSocket · The CAP theorem