Designing Uber: Geospatial Indexing, WebSockets, and Distributed Locks

Designing a platform like Uber might seem straightforward at first glance—just match a rider with a driver, right? But when you get into the details of real-time location tracking, geospatial querying, and concurrent bookings, it becomes an incredibly hard system to scale and maintain. Without any filler, let's dive into the architecture. System Requirements Functional Requirements: Users can input a source and destination to calculate a fare. Users can view nearby available drivers in real-time. Users can book a ride. Drivers can accept or reject ride requests. Non-Functional Requirements: Strict Consistency (for matching): Two drivers cannot accept the exact same ride. Low Latency: Ride matching must happen in < 1 minute. High Availability: Location tracking and routing must remain highly available. Scalability: Must support millions of concurrent users and high-frequency location updates. Core Entities User Ride High-Level Architecture Here is a look at the core components of our sy