What is Interview Forge?

Interview Forge helps you practice mock interviews, follow study plans, track career goals, review learning analytics, and prepare across 36 pages.

Design Uber (Ride-Hailing)

Requirements & scope

Functional: riders request a ride, nearby drivers are matched, a driver accepts, the trip is tracked live, fare is computed and charged, ratings are exchanged.
Non-functional: low-latency matching (<3s), high availability, accurate ETA, consistent and auditable pricing, fair dispatch.
Scale: millions of drivers and riders, ~10M trips/day in a large metro, ~100K driver location updates/sec.
Consistency: driver location is eventually consistent (last-write-wins with a short TTL is fine); trip state and fare must be strongly consistent.

Out of scope (covered in detail below)

Driver onboarding/verification, in-app payments plumbing, marketing, pool/shared rides, and scheduled rides — deferred and discussed in the dedicated section.

Capacity estimation

Resource	Estimate	Notes
Driver location updates	~100K/s	Each driver pings every 3-5s
Ride requests	~1K/s peak	10M trips/day, concentrated at rush hours
Live trip tracking	~1M concurrent trips	Each emits location updates
Geospatial index size	~tens of GB	Driver id -> (lat,lng), TTL ~10s

Architecture overview

Uber — dispatch & tracking

Hover a node to highlight its connections, or click a node to see its role. Location ingestion is decoupled from dispatch; the geospatial index is the hot path.

ClientServiceDatastoreCacheQueueExternal

Step-by-step request flow

Driver app sends GPS pings (every 3-5s) to the location ingestion service, which upserts (driver_id -> lat,lng) in the geospatial index with a short TTL.
Rider requests a ride; the dispatch service queries the geospatial index for the nearest N available drivers (the rider's geocell + neighbors).
Dispatch broadcasts a trip offer to those drivers; the first to accept wins (optimistic concurrency — the others are cancelled).
The trip service drives the state machine: requested -> accepted -> en_route -> ongoing -> completed, persisting each transition.
On completion, the pricing service computes the fare (base + time + distance + surge) and the payment service charges the rider and pays the driver.

Unlock the full guide

Premium members get every DSA, system design, company and role interview guide — plus AI practice, mock interviews, and analytics.

Unlock with Premium