Systems/Intermediate · about 45 min · 5 stages
Design a Ride-Sharing Service (Uber-style)
Design the dispatch path for a ride-sharing marketplace: find nearby eligible drivers quickly, avoid assigning one driver twice, and recover when location data or notifications arrive late.
The situation
A ride-hailing app lets a rider request a pickup and destination. The service finds nearby available drivers, estimates pickup time, offers the trip, and tracks the ride until it ends. A driver can be offered only one trip at a time, and a rider must never see two drivers accept the same request.
In one large city, about 60,000 drivers are online at peak. Each app sends a location update every 3 seconds while available. The marketplace handles about 2,000 ride requests a minute on average, with short 5× peaks after events and during bad weather. A candidate offer should reach a driver in about a second. A stale map pin is worse than no pin: drivers who have not reported in ten seconds are not eligible for a new match.
The design below is a practice problem, not a description of Uber's private architecture. Uber has publicly described H3, a hierarchical hexagonal grid used for marketplace analysis and dispatch-related decisions; the exercise asks you to choose and defend a design under its own assumptions.
What it has to do
Functional
- Create a ride request with pickup and destination, then show its status to the rider.
- Find nearby eligible drivers and send them a trip offer with a pickup estimate.
- Let a driver accept or decline an offer, and let the rider cancel before pickup.
- Track driver location and trip state until pickup, completion, or cancellation.
Non-functional
- Return an initial driver offer within about one second at peak.
- Never assign one driver to two active trips or accept two drivers for one trip.
- Never match a driver whose last location update is more than ten seconds old.
- A delayed push notification must not create a second assignment or reverse a newer trip state.
Constraints and assumptions
- 60,000 online drivers in the city, sending one location update every three seconds while available.
- 2,000 ride requests a minute on average; peaks reach five times the average for several minutes.
- The first offer should be sent within about one second; pickup estimates should use road travel time.
- Start with one city and one primary database; the system may later expand to many cities and regions.
- A driver can take one active ride at a time, and available drivers opt in to location sharing.
- Location is a short-lived hint for matching, not the durable record of a completed trip.
- A routing service can estimate pickup time for a small candidate set, but calling it for every driver is too slow and costly.
- Push delivery is at least once in practice: messages can be delayed, retried, or arrive out of order.
The questions it prepares you for
- Design Uber or Lyft's ride-sharing dispatch system.
- Find the nearest available driver to a pickup under a one-second latency target.
- Design a real-time driver-location service for multiple cities.
- Match couriers to delivery orders while preventing duplicate assignments.
- Handle a stadium event that creates a sudden, localized demand spike.
Read and practise next
From the source
- How Uber built itPush instead of polling
Concepts to know first