Design Uber Backend

A rider opens the app and sees 8 cars nearby. Within 3 seconds of tapping "Request," one is assigned. Behind that 3-second window: millions of GPS pings per minute, a spatial index queried on every request, and a matching algorithm that must never assign one driver to two riders simultaneously.

Functional

Real-time location tracking: Drivers broadcast GPS coordinates every 3-5 seconds. The system ingests these updates and maintains a live map of all active drivers. Riders see nearby drivers on their map in near real-time.

The numbers reveal why naive "scan all drivers" fails. 500K active drivers each sending GPS every 3 seconds equals 170K location writes per second. A ride request must search through these, and a full table scan will not finish in 3 seconds.

Users and Traffic

Start with the user base: 100 million registered riders, 5 million registered drivers. But registered users are not the same as active users. At peak hours (Friday evening, Saturday night), roughly 500K drivers are concurrently active (online and accepting rides), and 200K riders are concurrently looking for or on rides. Total rides completed: 2 million per day globally, averaging 23 rides per second with peaks reaching 200 per second during rush hour in major cities.

Two communication patterns define this system. REST for discrete actions like requesting a ride or accepting an offer. WebSocket for continuous streams like driver location updates. The choice between them is not arbitrary, it is driven by the traffic pattern of each endpoint.

Sending 170K location updates per second over HTTP would create 170K TCP handshakes per second, each carrying 500+ bytes of HTTP headers for a 100-byte payload. WebSocket keeps the connection open, amortizing the handshake cost across thousands of messages and reducing per-message overhead to a few bytes of framing.

REST Endpoints

Three storage tiers, each optimized for a different access pattern. Redis for real-time location at sub-millisecond latency with 30-second expiry. PostgreSQL for trip lifecycle with ACID transactions. Cassandra for location history with append-only, write-optimized storage.

Redis: Live Spatial Index

Redis holds the real-time driver map, the data structure that makes sub-second matching possible. The key design decision is how to organize drivers for spatial lookup.

Five services, one spatial index. The architecture separates concerns by access pattern: Location Service handles high-throughput writes, Ride Service handles transactional operations, and Matching Service handles CPU-intensive spatial queries. Kafka sits in the middle, decoupling producers from consumers so a slow analytics pipeline never blocks real-time matching.

The key insight: the critical path (driver GPS to Redis to matching) must be as short as possible. Everything else (history storage, surge computation, analytics) runs asynchronously off the same event stream.

Two flows define this system, and they have opposite characteristics.

The location update flow runs 170K times per second, is write-heavy, and must be fire-and-forget so it never blocks the driver app. A dropped or delayed GPS ping is tolerable, the next one arrives in 3 seconds.

The ride request flow runs 200 times per second at peak, is read-heavy against the spatial index, and must complete within 3 seconds including driver notification and response. A failed ride request directly impacts revenue and rider trust. These opposing requirements explain why the two flows share infrastructure (Redis, Kafka) but follow entirely different code paths.

"How do you find nearby drivers?", this is the real interview question hidden behind the system design prompt. Everything else (REST APIs, database schema, service decomposition) is standard. The spatial indexing strategy is what makes this problem uniquely interesting.

A naive scan of 500K drivers is O(N) per request. At 200 requests per second, that is 100 million distance calculations per second, impossible to sustain. Spatial indexing makes it O(1) by pre-partitioning geographic space so each query only examines the drivers in a small area, typically a few dozen candidates instead of half a million.

Three main approaches exist for partitioning geographic space. Each makes different trade-offs between simplicity, uniformity, and adaptivity.

Three cascading decisions define this architecture. Each one has a clear winner at Uber's scale, but the alternatives are valid at different scales or constraints. Understanding when each alternative becomes the better choice demonstrates architectural maturity.

The decisions: which spatial index, whether to stream or poll driver locations, and how to handle the matching transaction when two ride requests target the same driver.

Spatial Index: H3 vs Geohash vs Quadtree

Every distributed system fails. The question is not whether components will fail but how the system behaves when they do. For Uber, a 5-minute outage during Friday evening rush hour means thousands of stranded riders and millions in lost revenue.

Redis holds the spatial index, if it goes down, no rides match. A Kafka broker failure stops analytics but must not stop matching. A hot cell (concert venue with 10K ride requests in 5 minutes) overwhelms a single Redis shard. Each failure mode has a specific mitigation strategy.

Redis Primary Failure

The core system handles matching and rides reliably. These four extensions take it from functional to world-class, and each builds on the spatial indexing and real-time location infrastructure already in place rather than requiring new fundamental capabilities.

ML-Based Matching

The simplest improvement with the highest impact. Move from "nearest available driver" to "best available driver." Factors beyond ETA include driver acceptance rate (a driver who rejects 50% of offers wastes matching cycles and adds 15 seconds per rejection to the rider's wait), driver rating, route familiarity (a driver who frequently drives the pickup-to-destination route knows shortcuts and avoids traffic), and real-time traffic predictions. The ML model scores each candidate on a weighted combination of these features, trained on millions of historical trips. The matching algorithm replaces the simple ETA sort with the model's ranking. The key insight: optimizing for "probability of a completed, high-rated trip" rather than "minimum ETA" produces better outcomes for both riders and drivers.