hard general · part of Practice Questions · Senior SWE Roadmap
Requirements to clarify
- Functional: rider requests a ride, matched to a nearby available driver, real-time location tracking during the trip, fare calculation.
- Non-functional: matching must happen in seconds, location updates are extremely high-volume (every driver, every few seconds), geographic sharding is natural (a rider in NYC never matches a driver in LA).
Core components
- Geospatial indexing: geohash or quadtree to bucket drivers by location so “find nearby drivers” is a fast range query instead of a full scan (see Design a Proximity Service).
- Matching service: given a rider’s location, query nearby available drivers, apply a matching algorithm (closest, or optimizing for overall system efficiency), and send a ride request.
- Location ingestion pipeline: drivers’ apps stream location updates — high write volume, often absorbed by a message queue before updating the geospatial index.
- Trip/state service: tracks trip lifecycle (requested → matched → in-progress → completed) and handles fare calculation.
Key tradeoffs
- Geographic sharding keeps most queries local, but requires careful handling near shard boundaries (a rider near the edge of one region needs drivers from the adjacent region too).