Design Uber / Ride Matching System

Understanding Requirements

Functional Requirements

Non-Functional Requirements

Capacity Estimation

Request Flow

RIDE_REQUESTED → Queue

Major Components

Client (Rider & Driver Apps)

API Gateway

User Service

User Service Schema

CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    
    name VARCHAR(255),
    email VARCHAR(255) UNIQUE,
    phone VARCHAR(20) UNIQUE,
    
    password_hash VARCHAR(255),
    
    user_type VARCHAR(20),   -- RIDER or DRIVER
    status VARCHAR(20),      -- ACTIVE, BLOCKED, DELETED
    
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);

CREATE TABLE rider_profiles (
    user_id BIGINT PRIMARY KEY,
    
    default_payment_method VARCHAR(50),
    preferences JSON,
    
    FOREIGN KEY (user_id) REFERENCES users(id)
);

CREATE TABLE vehicles (
    id BIGINT PRIMARY KEY,
    
    driver_id BIGINT,
    
    vehicle_type VARCHAR(50),   -- BIKE, AUTO, CAR
    license_plate VARCHAR(50) UNIQUE,
    color VARCHAR(50),
    
    created_at TIMESTAMP,
    
    FOREIGN KEY (driver_id) REFERENCES users(id)
);

CREATE TABLE ratings (
    id BIGINT PRIMARY KEY,
    
    from_user_id BIGINT,
    to_user_id BIGINT,
    ride_id BIGINT,
    
    rating INT CHECK (rating BETWEEN 1 AND 5),
    comment TEXT,
    
    created_at TIMESTAMP,
    
    FOREIGN KEY (from_user_id) REFERENCES users(id),
    FOREIGN KEY (to_user_id) REFERENCES users(id)
);

Location Service

Storage (Geo Index)

update_location(driver_id, lat, lon)

find_nearby(lat, lon, radius)

Location Service Schema

-- Logical representation (if persisted in a store like Cassandra or Redis-backed persistence)
CREATE TABLE driver_locations (
    driver_id BIGINT PRIMARY KEY,
    
    latitude DOUBLE,
    longitude DOUBLE,
    geohash VARCHAR(12),
    
    is_available BOOLEAN,
    last_updated TIMESTAMP,
    
    ttl INT
);

Ride Service

REQUESTED → MATCHED → ONGOING → COMPLETED → CANCELLED

Schema (RDBMS)

CREATE TABLE rides (
    ride_id BIGINT PRIMARY KEY,
    
    rider_id BIGINT,
    driver_id BIGINT,
    
    pickup_lat DOUBLE,
    pickup_lon DOUBLE,
    
    drop_lat DOUBLE,
    drop_lon DOUBLE,
    
    created_at TIMESTAMP
);

CREATE TABLE ride_status_history (
    id BIGINT PRIMARY KEY,
    
    ride_id BIGINT,
    
    status TEXT,
    updated_at TIMESTAMP,
    metadata JSON,
    
    FOREIGN KEY (ride_id) REFERENCES rides(ride_id)
);

Matching Service

Matching Logic

drivers = location_service.find_nearby(rider_loc)

for driver in drivers:
    if driver.is_available:
        notify(driver)

In a distributed system, multiple matching workers or API instances may process acceptance requests concurrently, which can lead to race conditions. A distributed lock ensures that only one process can acquire the “assignment right” for a specific ride at a given moment.

This is typically implemented using systems like Redis (SETNX with expiry) or coordination services like ZooKeeper, where a lock is acquired on a key such as ride_id. Once a driver acquires the lock, the Ride Service validates and finalizes the assignment, while other concurrent attempts fail gracefully.

To avoid deadlocks and ensure fault tolerance, locks are always associated with a timeout (TTL), so that if a process crashes while holding a lock, it is automatically released.

In practice, distributed locking is often combined with idempotent APIs and database-level constraints to provide an additional layer of safety, ensuring correctness even under extreme concurrency.

Notification Service

Pricing Service

Pricing Service Schema

CREATE TABLE pricing_rules (
    id BIGINT PRIMARY KEY,
    
    city VARCHAR(100),
    vehicle_type VARCHAR(50),   -- BIKE, AUTO, CAR
    
    base_fare DOUBLE,
    cost_per_km DOUBLE,
    cost_per_min DOUBLE,
    
    min_fare DOUBLE,
    cancellation_fee DOUBLE,
    
    valid_from TIMESTAMP,
    valid_to TIMESTAMP
);

CREATE TABLE surge_pricing (
    id BIGINT PRIMARY KEY,
    
    city VARCHAR(100),
    region_id VARCHAR(100),   -- geo bucket / zone
    
    surge_multiplier DOUBLE,
    demand INT,
    supply INT,
    
    updated_at TIMESTAMP
);

CREATE TABLE fare_breakdown (
    ride_id BIGINT PRIMARY KEY,
    
    base_fare DOUBLE,
    distance_fare DOUBLE,
    time_fare DOUBLE,
    
    surge_multiplier DOUBLE,
    
    taxes DOUBLE,
    discounts DOUBLE,
    
    total_fare DOUBLE,
    
    created_at TIMESTAMP
);

System Guarantees

Show moreShow lessSmoothing techniques are used to reduce noise and inconsistencies in raw GPS data, which can otherwise cause sudden jumps or inaccurate movement on the map. Since GPS signals are often affected by buildings, signal loss, or device limitations, raw coordinates cannot be used directly for precise tracking.

The system applies techniques such as moving averages or Kalman filtering to smooth out abrupt changes and produce a more stable trajectory. In addition, map matching is used to align GPS points to actual road networks, ensuring that the driver appears to follow realistic routes instead of drifting off-road.

In the context of ride systems, Kalman filtering helps refine GPS coordinates by accounting for factors like speed, direction, and previous positions.

Instead of trusting each raw GPS point, the filter continuously performs two steps: it predicts the next position based on past movement, and then updates that prediction using the new observed GPS value. This balances noise and motion, producing a smoother and more realistic trajectory.

Distributed locking

In practice, a lock is acquired on a shared key such as ride_id using systems like Redis or coordination services, and only the instance holding the lock is allowed to proceed with the operation. Other competing requests either wait or fail gracefully.

To maintain reliability, locks are always associated with a timeout (TTL) so they are automatically released if a service crashes, preventing deadlocks. Combined with idempotent operations and database constraints, distributed locking helps maintain consistency and correctness under high concurrency.

Conclusion