Uber

Overview

Uber’s ride-hailing platform connects millions of riders with drivers across 10,000+ cities worldwide. Its architecture must solve complex real-time problems: matching riders to nearby drivers, computing ETAs, tracking live locations, calculating dynamic pricing, and processing payments — all within seconds. The system processes millions of location updates per second and completes trip matching in under 10 seconds.

Scale

Requirements

High-Level Architecture

Loading diagram...

Key Components

Data Model

Loading diagram...

Geospatial Indexing with S2 Geometry

Uber uses Google S2 Geometry to solve the core problem of finding nearby drivers efficiently.

How S2 Works:

• Divides Earth’s surface into hierarchical cells using a Hilbert curve
• Each cell has a unique 64-bit ID
• Cells at level 12 (~3.3km²) are used as the primary partitioning unit

Finding Nearby Drivers:

1. Convert rider’s location to an S2 cell ID
2. Query the geospatial index for all drivers in that cell and neighbors
3. Filter by distance, then compute road-network ETA for top candidates
4. The matching algorithm selects the optimal driver

Why S2 over alternatives (Geohash, H3)?

• No edge-case distortion at poles or date line
• Hierarchical cells enable efficient range queries
• Cell IDs map naturally to distributed storage keys
• Better approximation of circular search areas

The geospatial index is sharded using Ringpop (consistent hashing) so each server owns a set of S2 cells, enabling horizontal scaling.

Loading diagram...

Dynamic Pricing (Surge)

Uber’s surge pricing balances supply and demand in real-time:

How Surge Works:

1. The city is divided into geospatial zones (hexagonal cells)
2. For each zone, compute the supply-demand ratio every few seconds
3. When demand > supply, apply a surge multiplier (e.g., 1.5x, 2.0x)
4. Higher prices incentivize more drivers to enter the zone
5. As supply increases, surge naturally decreases

ML-Based Demand Forecasting:

• Uses historical data, weather, events, and time patterns
• Predicts demand spikes before they happen (concert ending, sports game)
• Pre-positions drivers in anticipated high-demand areas

Pricing Components:

• Base fare + per-minute rate + per-mile rate
• Surge multiplier applied to the total
• Minimum fare and booking fee
• Tolls, airport fees, and surcharges

The pricing service must be extremely fast (<50ms) since it’s called for every ride request.

Real-Time Trip Tracking

Once a trip is in progress, Uber tracks it in real-time:

Location Pipeline:

1. Driver app sends GPS updates every 4 seconds
2. Updates flow through Kafka to the Location Service
3. Location Service updates the geospatial index and publishes to subscribers
4. Rider app receives real-time driver position via WebSocket

State Machine: Each trip follows a strict state machine:

• REQUESTED → ACCEPTED → ARRIVING → IN_PROGRESS → COMPLETED
• At each transition, specific actions are triggered (notifications, fare updates)

Route Snapping: Raw GPS coordinates are “snapped” to the road network to:

• Accurately calculate distance traveled (for fare computation)
• Show smooth movement on the map
• Handle GPS jitter in urban canyons and tunnels

Uber processes millions of GPS events per second through this pipeline.

Architectural Tradeoffs

# Learn From a Uber-like System

You are an expert software architect and teacher. I want to learn from a Uber-inspired system design (Real-time ride matching with geospatial intelligence) without pretending this is the exact private production architecture.

Use the following reference as a learning model. Keep assumptions visible, avoid unsupported scale claims, and explain the engineering forces behind each design choice.

---

## System Design Reference
import { Mermaid, Scale, ComponentList, ComponentCard, Requirements, Tradeoff } from '@/components/mdx';

## Overview

Uber's ride-hailing platform connects millions of riders with drivers across 10,000+ cities worldwide. Its architecture must solve complex real-time problems: matching riders to nearby drivers, computing ETAs, tracking live locations, calculating dynamic pricing, and processing payments — all within seconds. The system processes millions of location updates per second and completes trip matching in under 10 seconds.

## Scale

<Scale items={{
  "Monthly active riders": "130M+",
  "Trips per day": "~28M",
  "GPS updates/second": "Millions",
  "Trip & location data": "Petabytes",
}} />

## Requirements

<Requirements
  functional={[
    'Rider-driver matching based on proximity and ETA',
    'Real-time GPS tracking of rides',
    'Dynamic pricing (surge pricing)',
    'ETA estimation and route optimization',
    'Payment processing and fare calculation',
    'Trip history and receipts',
    'Driver and rider ratings',
  ]}
  nonFunctional={[
    'Sub-10 second ride matching',
    'Real-time location processing at massive scale',
    'High availability across cities worldwide',
    'Accurate ETA predictions',
    'Fraud detection in real-time',
    'Support for millions of concurrent GPS streams',
  ]}
/>

## High-Level Architecture

<Mermaid chart={`graph TB
    subgraph Clients
        RA[Rider App]
        DA[Driver App]
    end
    subgraph Edge
        AG[API Gateway]
        LB[Load Balancer]
...

[Full prompt copied to clipboard]