Back to System Design
System Design
Ride-sharing system
Senior level · full staged walkthrough
Senior
Architecture
SeniorClientServiceData
Solution, step by step
- 1
Functional requirements
- Match riders to nearby drivers
- Live driver/rider location
- Pricing, ETA, and trip lifecycle
- 2
Non-functional requirements
- Match latency < a few seconds
- Location updates every few seconds
- Geo-accuracy vs write volume balance
- High availability in a region
- 3
Capacity & estimation
- 1M active drivers → location writes ~200K/s (every 5s)
- Matching queries scoped to nearby geo cells
- Trip records: millions/day
- Surge computed per region/time bucket
- 4
Preliminary design
- Geo-index drivers (geohash/quadtree)
- Match service queries nearby cells
- Stream location updates over WS
- 5
Final architecture
- Location service ingests GPS via WS into an in-memory geo index (Redis GEO/quadtree)
- Matching engine queries nearby cells, scores candidates, dispatches offers
- Pricing service computes surge from supply/demand per region
- Trip service manages lifecycle/state machine; durable trip store
- Notification service updates both parties in real time
Interview Q&A (8)
Index driver locations in an in-memory geo structure (geohash/quadtree or Redis GEO) and query only the cells near the rider.
Key components
- Location service
- Matching engine
- Pricing service
- Trip store
- Notification service
Bottlenecks & how to address them
- Location write volume → in-memory index + batched persistence
- Dense-city hotspots → finer geo sharding
- Matching contention → per-cell locking/queues
Tradeoffs to articulate
- Geohash precision vs match quality
- Real-time vs batched location writes
- Surge pricing fairness vs revenue
Where this content comes from
For full transparency, this content is curated and verified from these sources:
Published architecture case studiesCompany engineering blogsOppZen design rubric library