Ride Sharing (Uber)

Overview

Designing a Ride Sharing system (Uber, Lyft) is a challenging question that tests real-time matching, geolocation, and distributed state. The core challenges include: matching riders with nearby drivers, tracking live locations, handling surge pricing, and ensuring consistency when multiple users see the same driver. This design matters in interviews because it combines WebSockets for real-time updates, spatial indexing (geohash, grid) for proximity search, and event-driven architecture for matching. Companies like Uber and Lyft operate at massive scale with strict latency requirements, and demonstrating you understand the full flow from request to match to trip completion shows you can design complex real-world systems.

Requirements

Functional

Request ride with pickup/dropoff locations
Match rider with nearby available driver
Real-time driver location tracking
Surge pricing based on demand
Trip lifecycle: request → match → ongoing → complete
Payment processing

Non-Functional

Low latency — match within seconds
High availability — critical for safety
Consistency — driver assigned to only one rider
Scalability — millions of concurrent users

Capacity Estimation

Assume 10M daily rides, 1M concurrent users. 100K location updates/sec. Matching: 10K requests/sec. Need <5 sec match latency.

Architecture Diagram

Component Deep Dive

Location Service

Receives driver/rider GPS updates. Stores in spatial index (Redis Geo, Geohash). Publishes to matching.

Matching Service

Finds available drivers within radius of pickup. Uses geohash grid. Assigns driver, ensures atomicity.

Trip Service

Manages trip state: requested, matched, in_progress, completed. Coordinates with payment.

Pricing Service

Calculates fare. Surge multiplier based on demand/supply ratio. Historical and real-time data.

Notification Service

Push/WebSocket to driver and rider. Match result, ETA, trip updates.

Payment Service

Charges rider, pays driver. Integrates with payment gateway. Handles splits and tips.

Database Design

Users, drivers, trips in PostgreSQL. Location in Redis Geo or Cassandra with geohash. Trip events in Kafka for analytics. Payment records in transactional DB.

API Design

Method	Path	Description
`POST`	/api/rides	Request ride. Body: {pickup, dropoff}. Returns ride_id.
`GET`	/api/rides/{id}	Get ride status, driver location.
`PUT`	/api/drivers/location	Update driver location (frequent).
`POST`	/api/rides/{id}/complete	Complete trip. Triggers payment.

Scalability & Trade-offs

Push vs pull matching: Push (notify drivers) vs pull (driver polls). Push is more efficient; pull is simpler.
Consistency: Strong consistency for assignment (one driver, one rider); eventual for location updates.
Geospatial: Geohash is simple; quadtree or H3 allows variable resolution.

Related System Designs

Real-time