Design a Ride-Hailing Service (Uber/Lyft)

To design the core matching system for a service like Uber, I would start by defining our non-functional requirements: sub-200ms matching latency and 99.9% availability. First, we need a robust geospatial indexing strategy. Instead of querying a flat SQL database, I would implement a Geohash-based indexing layer. This divides the earth into variable-resolution grids; a driver's current location generates a hash string that allows us to instantly retrieve all nearby riders within a specific radius. For high-volume matching, we cannot iterate through all drivers. We would use a two-phase approach: Phase one filters candidates using the Geohash index to find drivers within a 5km dynamic radius. Phase two applies a scoring algorithm to rank these candidates, prioritizing shortest ETA, highest driver rating, and minimizing rider wait time. To estimate ETAs accurately, we would integrate a real-time traffic engine that pulls historical speed data from similar road segments and adjusts for live congestion events. Location tracking requires a dedicated stream processor, likely built on Kafka or Pulsar, to ingest GPS pings from mobile devices. These updates are normalized and stored in a columnar store optimized for time-series queries, such as Cassandra or HBase, partitioned by city ID to ensure local scaling. Finally, to handle global scale, we would shard our services geographically, ensuring that a query for New York drivers never touches servers hosting London data, thereby minimizing network hops and maximizing throughput.