Skip to content

Uber Ride Sharing System

Quick Reference Guide for System Design Interviews

Problem Statement

Design a ride-sharing platform like Uber that matches riders with nearby drivers, handles real-time location updates, and processes trip requests at scale.

Requirements

Functional Requirements

  • Rider requests a ride
  • Match with nearby available drivers
  • Real-time driver location tracking
  • Trip fare calculation
  • Payment processing
  • Rating system
  • Trip history

Non-Functional Requirements

  • Latency: < 1s for driver matching
  • Availability: 99.99%
  • Scale: 100M users, 15M trips/day
  • Location Updates: Every 3-4 seconds per driver

Back of Envelope Estimation

Capacity Estimation

High-Level Architecture

Uber Architecture

Geospatial Indexing

Geospatial Indexing

Location Service

Location Service

Trip Matching

Trip Matching

Trip Lifecycle

Trip Lifecycle

Fare Calculation

Fare Calculation

Data Models

-- Drivers table
CREATE TABLE drivers (
    driver_id       UUID PRIMARY KEY,
    name            VARCHAR(100),
    phone           VARCHAR(20),
    vehicle_id      UUID REFERENCES vehicles(id),
    status          ENUM('offline', 'available', 'on_trip'),
    rating          DECIMAL(3,2),
    total_trips     INT DEFAULT 0,
    created_at      TIMESTAMP
);

-- Trips table
CREATE TABLE trips (
    trip_id         UUID PRIMARY KEY,
    rider_id        UUID NOT NULL,
    driver_id       UUID,
    status          VARCHAR(20),

    -- Locations
    pickup_lat      DECIMAL(10, 7),
    pickup_lng      DECIMAL(10, 7),
    dropoff_lat     DECIMAL(10, 7),
    dropoff_lng     DECIMAL(10, 7),

    -- Trip details
    distance_miles  DECIMAL(6, 2),
    duration_mins   INT,

    -- Pricing
    base_fare       DECIMAL(10, 2),
    surge_multiplier DECIMAL(3, 2) DEFAULT 1.0,
    total_fare      DECIMAL(10, 2),

    -- Timestamps
    requested_at    TIMESTAMP,
    accepted_at     TIMESTAMP,
    started_at      TIMESTAMP,
    completed_at    TIMESTAMP,

    INDEX idx_rider (rider_id, requested_at),
    INDEX idx_driver (driver_id, requested_at)
);

-- Real-time location (Redis)
-- HSET driver:123:location lat 37.7749 lng -122.4194 timestamp 1705312200
-- SADD drivers:available:geohash:9q8yy driver:123

Real-time Communication

Real-time Communication

Interview Discussion Points

  1. How do you find nearby drivers efficiently?
  2. Geohash or QuadTree indexing
  3. Query current + neighboring cells

  4. Filter by distance and availability

  5. How do you handle 500K location updates/second?

  6. In-memory (Redis) for current locations
  7. Batch writes to persistent storage

  8. Geo-sharding by region

  9. How does surge pricing work?

  10. Supply/demand ratio per zone
  11. Real-time computation

  12. Multiplier shown before booking

  13. How do you ensure trip matching is fair?

  14. First-come-first-served for riders
  15. Rotate drivers to avoid starvation

  16. Consider acceptance rate

  17. How do you handle driver going offline during trip?

  18. Heartbeat detection
  19. Auto-reassign if no response

  20. Edge cases for accidents

  21. How do you scale globally?

  22. Regional deployments
  23. City-level data isolation
  24. Geo-routing at DNS level