System Design Deep Dive: How Uber Calculates Surge Pricing in Real-Time

Introduction to Surge Pricing

When interviewing for Senior or Staff engineering roles at companies like Uber, Lyft, or DoorDash, you will almost certainly encounter a system design question centered around real-time geospatial data and dynamic pricing.

Surge pricing (or dynamic pricing) is the mechanism that balances supply (drivers) and demand (riders) by adjusting prices based on real-time market conditions. In this deep dive, we'll architect a system capable of calculating these prices globally with sub-second latency.

1. Requirements & Scale Estimation

Before drawing boxes, we must establish the constraints.

• Daily Active Users (DAU): 50 Million riders, 5 Million drivers.
• Location Updates: Drivers send GPS pings every 5 seconds. Riders ping when opening the app.
• Write Heavy: ~1 Million driver location updates per second globally.
• Read Heavy: ~500,000 rider fare estimates per second during peak hours.

Key Challenge: This is an extremely write-intensive system. Traditional SQL databases will choke under 1M writes/sec if not aggressively sharded.

2. Geospatial Indexing: The Core Data Structure

To calculate surge, we must know exactly how many drivers and riders are in a specific area right now.

We divide the world into geographical grids. Uber famously uses H3 (Hexagonal Hierarchical Spatial Index), while others might use S2 (Google) or Geohash. When a driver pings their location `(lat, long)`, we convert it to an H3 index (e.g., resolution 8, which represents an area of ~0.7 sq km).

Storing Real-time Locations

We cannot write 1M updates/sec to Postgres. Instead, we use a high-throughput, in-memory store like Redis or a specialized geospatial cluster.

• Redis Geo: We can store `GEOADD driver_locations long lat driver_id`.
• Better Approach (In-Memory Grid): Since we only care about the count per hex, we can use a distributed in-memory cache (like Redis or Memcached) to maintain counters: `INCR hex_id_supply` and `INCR hex_id_demand`.

3. The Surge Aggregation Pipeline (Streaming)

We need to aggregate supply and demand streams in real-time. This is a perfect use case for Stream Processing.

1. Ingestion: Mobile apps send location pings to an API Gateway, which forwards them to Apache Kafka. Kafka partitions data by `hex_id` to ensure order and locality.
2. Processing: Apache Flink or Spark Streaming consumes the Kafka topics. Flink maintains a tumbling window (e.g., 10 seconds).
3. Aggregation: Flink calculates the sum of active drivers and requesting riders per `hex_id` every 10 seconds.
4. Surge Calculation Model: The aggregated data is passed to a Machine Learning Model Service. The model considers:
   • Current Supply / Demand ratio
   • Historical data for this hex at this time
   • Traffic/Weather APIs
5. Output: The model outputs a surge multiplier (e.g., 1.5x) and saves it to a fast-read database (Redis or Cassandra).

4. Serving the Rider Request

When a rider opens the app and requests a fare estimate:

1. The Rider Service determines the rider's `hex_id`.
2. It queries the Surge Redis Cache for the current multiplier.
3. It queries the Routing Service (which uses map data) to calculate base time and distance.
4. `Final Price = (Base Fare + Time + Distance) * Surge Multiplier`.

5. Handling System Failures (Resiliency)

What if the Flink cluster goes down? You cannot stop people from booking rides.

• Fallback Mechanism: If the real-time surge multiplier cannot be fetched within 200ms, fall back to a "historical average" surge pre-calculated by a daily batch job (Hadoop/Spark) stored in DynamoDB.
• Graceful Degradation: The rider gets a ride, the system catches up later.

Master System Design Interviews

This is exactly the type of architectural depth expected in L5/L6 interviews. Knowing what Kafka is isn't enough; you must explain why it partitions by `hex_id`.

If you want to practice this exact scenario with a live, voice-based AI interviewer that pushes you on these constraints, try the Uber Surge Pricing scenario on EngMock.com. Our AI will grade your DB choices, your QPS math, and your streaming architecture in real-time.