Design Uber: System Design Interview Guide

Designing Uber is a classic system design interview question that tests your ability to build a real-time, location-based, and highly scalable service. Uber connects riders with drivers, handles payments, provides real-time tracking, and operates in hundreds of cities worldwide. In this guide, we'll walk through the key components, trade-offs, and design decisions you need to discuss in an interview. You'll learn how to break down the problem, estimate scale, design the data model, and architect the system for high availability and low latency. Whether you're preparing for a FAANG interview or just want to understand large-scale system design, this article covers everything from ride matching to surge pricing. Let's dive in and design Uber like a pro.

1. Requirements and Scale Estimation

Start by clarifying functional and non-functional requirements. For Uber, functional requirements include: rider requesting a ride, driver accepting, real-time tracking, fare calculation, and payment processing. Non-functional: low latency (< 1s for ride matching), high availability (99.99%), scalability to millions of users, and consistency for payments. Estimate scale: assume 100 million daily active users, 10 million rides per day, and 1 million drivers online. Each ride generates location updates every 5 seconds, so we need to handle ~2 million location updates per second. Storage: each ride record ~1KB, so 10 million rides/day = 10GB/day, 3.6TB/year. This drives our design choices.

2. High-Level Architecture

We'll use a microservices architecture with an API gateway. Key services: Ride Service (handles ride requests), Driver Service (manages driver availability), Location Service (processes real-time location updates), Pricing Service (calculates fares), Payment Service, and Notification Service. The API gateway routes requests, handles authentication, and rate limiting. For real-time communication, we use WebSockets for location streaming and push notifications. Message queues (Kafka) decouple services for asynchronous processing, e.g., ride matching events. A service mesh (e.g., Istio) can handle service-to-service communication and observability.

Client (Mobile App) -> API Gateway -> Ride Service -> Driver Service -> Location Service
                    -> Pricing Service -> Payment Service -> Notification Service
                    -> Message Queue (Kafka) for async events
                    -> Database (SQL for transactions, NoSQL for location data)
                    -> Cache (Redis) for session data and driver locations

3. Data Model

We need to model users (riders and drivers), rides, and locations. For relational data (users, rides, payments), we use SQL (e.g., PostgreSQL) with sharding by user_id or city. For location data, we use a NoSQL database like Cassandra or DynamoDB for high write throughput. Key tables: Users (user_id, name, phone, role), Drivers (driver_id, user_id, status, current_location, car_details), Rides (ride_id, rider_id, driver_id, status, pickup, dropoff, fare, timestamps). Location updates are stored as time-series data. We also need a geospatial index for efficient driver search – we can use a QuadTree or GeoHash. For caching, Redis stores active driver locations and ride sessions.

CREATE TABLE users (
    user_id UUID PRIMARY KEY,
    name VARCHAR(100),
    phone VARCHAR(20) UNIQUE,
    role ENUM('rider', 'driver')
);

CREATE TABLE drivers (
    driver_id UUID PRIMARY KEY,
    user_id UUID REFERENCES users(user_id),
    status ENUM('online', 'offline', 'busy'),
    current_location GEOGRAPHY(Point),
    car_details JSONB
);

CREATE TABLE rides (
    ride_id UUID PRIMARY KEY,
    rider_id UUID REFERENCES users(user_id),
    driver_id UUID REFERENCES drivers(driver_id),
    status ENUM('requested', 'accepted', 'in_progress', 'completed', 'cancelled'),
    pickup GEOGRAPHY(Point),
    dropoff GEOGRAPHY(Point),
    fare DECIMAL(10,2),
    created_at TIMESTAMP DEFAULT NOW()
);

-- Index for location queries
CREATE INDEX idx_drivers_location ON drivers USING GIST (current_location);

4. Ride Matching Algorithm

When a rider requests a ride, we need to find the nearest available driver. The naive approach is to query all online drivers within a radius, but that doesn't scale. Instead, we use geospatial indexing. We can divide the map into grids (QuadTree) or use GeoHash. Each driver's location is mapped to a grid cell. When a request comes, we look up the rider's cell and neighboring cells to find drivers. We then calculate distances using Haversine formula and select the closest driver. To handle high throughput, we cache driver locations in Redis with TTL. For load balancing, we can use consistent hashing to distribute drivers across servers. Also, we need to consider surge pricing: if demand > supply in an area, increase price to balance. The pricing service uses a dynamic pricing model based on real-time demand-supply ratio.

import geohash2
from math import radians, sin, cos, sqrt, atan2

def find_nearest_driver(rider_location, available_drivers):
    # rider_location: (lat, lon)
    # available_drivers: list of (driver_id, lat, lon)
    
    def haversine(lat1, lon1, lat2, lon2):
        R = 6371  # Earth radius in km
        dlat = radians(lat2 - lat1)
        dlon = radians(lon2 - lon1)
        a = sin(dlat/2)**2 + cos(radians(lat1)) * cos(radians(lat2)) * sin(dlon/2)**2
        c = 2 * atan2(sqrt(a), sqrt(1-a))
        return R * c
    
    nearest = None
    min_dist = float('inf')
    for driver in available_drivers:
        dist = haversine(rider_location[0], rider_location[1], driver[1], driver[2])
        if dist < min_dist:
            min_dist = dist
            nearest = driver[0]
    return nearest, min_dist

# Example usage
rider = (37.7749, -122.4194)  # San Francisco
drivers = [
    ('d1', 37.7849, -122.4094),
    ('d2', 37.7649, -122.4294),
    ('d3', 37.7749, -122.4194)  # same location
]
nearest_driver, distance = find_nearest_driver(rider, drivers)
print(f"Nearest driver: {nearest_driver}, distance: {distance:.2f} km")

5. Real-Time Location Tracking

Drivers send their location every few seconds. We need to ingest this high-velocity data and broadcast to relevant riders. Use WebSockets for persistent connections. Each driver's location update is sent to a location service, which publishes to a Kafka topic. A stream processor (e.g., Apache Flink) updates the driver's location in the database and cache. For riders, we subscribe to the driver's location stream via WebSocket. To reduce load, we can batch updates or throttle frequency. For consistency, we use a last-write-wins strategy. Also, we need to handle disconnections gracefully – if a driver disconnects, mark them as offline after a timeout.

import asyncio
import websockets
import json

async def handle_driver_location(websocket, path):
    async for message in websocket:
        data = json.loads(message)
        driver_id = data['driver_id']
        lat = data['lat']
        lon = data['lon']
        # Update in cache and DB asynchronously
        await update_driver_location(driver_id, lat, lon)
        # Broadcast to rider if matched
        rider_ws = get_rider_websocket(driver_id)
        if rider_ws:
            await rider_ws.send(json.dumps({'driver_id': driver_id, 'lat': lat, 'lon': lon}))

start_server = websockets.serve(handle_driver_location, '0.0.0.0', 8765)
asyncio.get_event_loop().run_until_complete(start_server)
asyncio.get_event_loop().run_forever()

6. Handling Failures and Consistency

In a distributed system, failures are inevitable. We need to ensure data consistency, especially for payments. Use idempotency keys to prevent duplicate charges. For ride matching, we can use eventual consistency – it's okay if a driver is slightly outdated. For critical operations, use distributed transactions (e.g., two-phase commit) sparingly due to performance cost. Instead, use saga pattern: a sequence of local transactions with compensating actions. For example, if payment fails after ride completion, we can retry or cancel the ride. Also, implement circuit breakers for external services (e.g., payment gateway). For database failures, use replication and automatic failover. Cache failures can be mitigated by fallback to database.

7. Scaling and Performance Optimization

To handle millions of requests, we need horizontal scaling. Use sharding by city or region for databases. For location data, use consistent hashing to distribute driver locations across cache nodes. For the API gateway, use a load balancer (e.g., NGINX) with round-robin or least connections. For real-time processing, use stream processing frameworks like Apache Flink or Kafka Streams. Optimize database queries with proper indexing and denormalization. Use CDN for static assets. For surge pricing, precompute demand-supply ratios in batch jobs. Also, implement rate limiting to prevent abuse. Finally, monitor everything with distributed tracing (e.g., Jaeger) and metrics (Prometheus).

8. Interview Tips and Common Pitfalls

In the interview, start with requirements and estimation. Don't jump into details. Discuss trade-offs: SQL vs NoSQL, synchronous vs asynchronous, consistency vs availability. Be prepared to dive deep into one component, like ride matching or location tracking. Use whiteboard to draw architecture. Common mistakes: ignoring non-functional requirements, over-engineering, not considering failure scenarios. Also, don't forget about monitoring and logging. Practice with mock interviews. Finally, communicate clearly and ask clarifying questions.