Design a Ride Matching System (Uber / Ola)
An end-to-end interview-ready walkthrough — from capacity math through deep dives on geospatial indexing, real-time location ingestion, matching, surge pricing, ETA, and the ride state machine. Structured to mirror a 45-minute system design interview.
Requirements
A ride-matching system is deceptively complex. On the surface it's "connect rider to driver" — but underneath it's a real-time geospatial system with sub-second latency targets, millions of concurrent location updates, a multi-state lifecycle, and dynamic pricing that must respond to demand in real time. Anchor the scope before drawing a single box.
Functional Requirements
Core business logic & features
- 01.Ride Request & MatchingRider requests a ride from pickup to destination. System finds the best nearby available driver and sends a ride offer.
- 02.Real-time Driver LocationTrack all active drivers' GPS positions in real time. Update every 3–5 seconds via persistent connections.
- 03.ETA CalculationShow estimated time of arrival for both pickup (driver → rider) and trip (rider → destination).
- 04.Surge PricingDynamically adjust pricing based on demand/supply ratio per geographic region.
- 05.Ride Lifecycle ManagementManage ride states: REQUESTED → MATCHED → ACCEPTED → EN_ROUTE → IN_PROGRESS → COMPLETED / CANCELLED.
- 06.Driver Acceptance FlowSend ride offer to driver with a timeout. On rejection or timeout, re-match to next best driver.
Non-Functional
System constraints
Matching Latency
Match rider to driver in < 1 second. The matching decision is the product experience.
Scale
10M rides/day globally. 5M concurrent active drivers sending location every 4 seconds.
Availability
99.99% for ride requests. Downtime means stranded riders and lost revenue.
Consistency
A driver must never be double-booked. Ride state transitions must be strongly consistent.
🎯 Clarifying questions worth asking
Each one changes the design:
- Single rider or ride-pooling? (pooling changes matching from 1:1 to N:1 — fundamentally different algorithm)
- How many vehicle types? (economy, premium, XL — affects supply segmentation)
- Global or single-city? (multi-region adds geo-routing and data residency)
- How accurate must ETA be? (road-graph routing vs straight-line approximation)
- Is surge pricing transparent? (riders see multiplier before confirming — affects UX flow)
In scope vs out of scope
| In Scope | Out of Scope | Why |
|---|---|---|
| Single-rider matching | Ride pooling (shared rides) | Pooling is a separate optimization problem — different matching algorithm entirely |
| Surge pricing (demand/supply) | ML-based dynamic pricing models | Interview scope — rule-based surge is sufficient to demonstrate the architecture |
| ETA estimation | Full turn-by-turn navigation | Navigation is a separate product (Google Maps API). We estimate, not navigate. |
| Driver acceptance + re-matching | Driver scheduling / shift management | Operational concern, not a distributed-systems one |
| Basic fraud detection | ML-based fraud scoring pipeline | Mention as a callout, don't design the ML system |
| Payment hold before matching | Full payment processing system | Payment is a separate bounded context — we just call a hold API |
💡 Interviewer signal
Candidates who say "I'll use a geospatial index" in the first minute lose credibility. State the constraints first: "matching must be under 1 second, location updates are 1M writes/sec, and a driver can never be double-booked" — that frames every decision that follows.