Uber Design (Ride-Hailing)

0) Problem Restatement

Design a ride-hailing service like Uber where riders can request rides, and drivers are matched with them in real-time. Key challenges include highly accurate location tracking, low-latency matching, handling demand spikes (surge pricing), and maintaining strong consistency for payments and trip records across millions of concurrent sessions.

1) Requirements

1.1 Functional

• Request Ride: Rider provides pickup/dropoff and requests a vehicle.
• Driver Matching: System finds the nearest available driver.
• Real-time Tracking: Rider and driver can see each other's live location.
• Payments: Automatic fare calculation and processing.
• Ratings: Both parties rate each other post-trip.

1.2 Non-Functional

• Low Latency: Matching and updates must happen in < 1-2 seconds.
• High Availability: Service must be operational globally 24/7.
• Scalability: Support millions of drivers and riders simultaneously.
• Consistency: Critical for trip states and wallet/payment transactions.

1.3 Scale Estimates

• DAU: 20 Million riders, 2 Million drivers.
• Trips per Day: 5 Million.
• Ride Requests: 5M trips/day ÷ 86,400 s ≈ 58 trips/sec on average. Demand is peaky (rush hour, events, bad weather), so plan for ~10× → ~600 ride requests/sec at peak. Each request triggers several match attempts (drivers decline or time out), so ~2–3K dispatch offers/sec.
• Active drivers at peak: 2M registered drivers online at once is the upper bound.
• Location Updates: 2M online drivers ÷ 5-second interval = ~400K writes/sec — by far the heaviest load in the system, and why location lives in memory, not in the trip database.

1.4 API Design

The core APIs required for the service:

• Request Ride: POST /v1/rides/request - Initiate a trip request.
• Update Location: POST /v1/driver/location - Driver heartbeat and GPS.
• Accept Ride: POST /v1/driver/accept - Driver claims a match.
• Complete Trip: POST /v1/rides/:id/complete - Trigger payment and rating.

2) High-Level Architecture

2.1 Overview

• Matching Service: Uses geospatial indexing (like S2/H3) to find nearest drivers.
• Location Service: High-throughput ingestion for driver GPS heartbeats.
• Trip Service: Manages the lifecycle and state machine of a ride.
• Payment Service: Integrates with external gateways for secure transactions.

2.2 Architecture Diagram

flowchart LR
    %% User Apps
    RA[Rider App / Web]
    DA[Driver App]

    %% API Gateway
    APIGW[API Gateway]

    %% Core Services
    RS[Rider Service]
    DS[Driver Service]
    LS[Location Service]
    Geo[(Geo Index<br/>drivers by H3 cell, in memory)]
    PR[Pricing / Surge Service]
    MS[Matching Service]
    TS[Trip Service]
    PS[Payment Service]
    NS[Notification Service]
    RideDB[(Ride DB)]
    UserDB[(User DB)]
    Cache[(Redis / In-Memory)]

    %% Async & Analytics
    MQ[(Message Queue / Kafka)]
    CRM[CRM / Analytics]

    %% Connections with labels
    RA -->|Ride Request| APIGW
    DA -->|Driver Availability / Status| APIGW

    APIGW -->|Route Rider Requests| RS
    APIGW -->|Route Driver Updates| DS
    DA -->|GPS every 5s ~400K/s| LS
    LS -->|Update driver cell| Geo

    RS -->|Quote fare| PR
    PR -->|Supply/demand per cell| Geo
    RS -->|Rider Info / Request| MS
    DS -->|Driver Info / Status| MS
    MS -->|Nearby available drivers| Geo
    MS -->|Match Rider & Driver| TS
    TS -->|Persist Trip Info| RideDB
    TS -->|Send Notifications| NS

    RA <-->|Track Trip / Updates| TS
    DA <-->|Track Trip / Updates| TS

    RA -->|Make Payment| PS
    PS -->|Update Ride Status| RideDB

    TS -->|Emit Trip Events| MQ
    MQ -->|Consume Events| CRM
    RideDB -->|Sync Trip Data| CRM
    UserDB -->|Sync User Data| CRM

    Cache -->|Fast Access Data| MS

    %% Color coding
    classDef userFlow fill:#f0f8ff,stroke:#333,stroke-width:1px;
    classDef coreService fill:#e0ffe0,stroke:#333,stroke-width:1px;
    classDef asyncFlow fill:#fff0f0,stroke:#333,stroke-width:1px;

    class RA,DA userFlow;
    class APIGW,RS,DS,LS,Geo,PR,MS,TS,PS,RideDB,UserDB,Cache,NS coreService;
    class MQ,CRM asyncFlow;

3) Data Model

Trips Table (Strong Consistency)

{
  "trip_id": "UUID",
  "rider_id": "UUID",
  "driver_id": "UUID",
  "pickup_location": "Geography",
  "dropoff_location": "Geography",
  "status": "enum (requesting, matched, in_progress, completed)",
  "fare": "decimal",
  "created_at": "timestamp"
}

4) Flows

4.1 Matching Flow

1. Rider requests a ride; Pricing Service calculates surge.
2. Matching Service queries Geospatial Index for nearby "active" drivers.
3. System sends push notifications to drivers in waves (nearest first).
4. First driver to accept is tied to the trip ID in a transaction.

5) Scale Considerations

• Geospatial Sharding: Use H3 cells to shard the matching engine so London and NYC matchings don't compete for the same server.
• Surge Pricing: Implement a separate low-latency service that monitors supply/demand ratios per cell.
• WebSocket Gateway: Maintain persistent connections for live location updates.

6) Deep Dive Topics

6.1 Geospatial Indexing (Quadtrees vs. H3)

• Quadtrees: Good for static data but hard to re-balance for moving objects (drivers).
• H3 (Uber's Choice): Uses hexagonal tiling. Every neighbor of a hexagon is the same distance from its center (squares have closer edge neighbors and farther corner neighbors), so "search the ring of cells around the rider" covers a near-circular area evenly. The geo index only finds *candidate* drivers by straight-line proximity; the actual ETA comes from a routing engine over the road network.
• Sharding: By using H3 cell IDs as shard keys, we ensure that matching requests for "Downtown SF" are processed by a dedicated cluster of matching engines.

6.2 Consistency & Distributed Transactions

• The Double-Accept Problem: Two drivers accept the same ride at the same millisecond.
• Solution: Use atomic UPDATE with a WHERE status = 'requesting' clause or a distributed lock (Redis/Zookeeper) to ensure only one driver is tied to a Trip ID.

7) Tradeoffs & Extensions

7.1 Tradeoffs

• WebSocket vs. HTTP Heartbeats: WebSockets provide lower latency for "car moving on map" but require significantly more server memory. Uber uses a mix of highly optimized UDP/HTTP heartbeats for basic location and WebSockets for active "on-trip" views.
• ACID vs. BASE: High availability (AP) is needed for location updates, but strict consistency (CP) is non-negotiable for payments and trip history.

7.2 Extensions

• Uber Pool (Matching Optimization): A dynamic ride-sharing / vehicle routing problem (NP-hard in general): insert new riders into existing trips while respecting pickup windows and max detour. Solved with heuristics — try inserting the new rider into each nearby car's route and pick the cheapest feasible insertion.
• Dynamic Routing: Integrating real-time traffic data to provide hyper-accurate ETAs.

8) Wrap-Up

Designing Uber requires balancing extreme write throughput (driver heartbeats) with complex real-time matching. By leveraging hexagonal geospatial indexing and a robust trip state machine, the system provides a seamless experience for millions of concurrent users.