System Design

Designing a Ride-Hailing System at Scale: Geolocation, Matching Engine & Surge Pricing

Uber handles 20 million trips per day, matching riders to drivers in under 15 seconds anywhere in the world. The technical challenges are deceptively hard: tracking hundreds of thousands of driver GPS positions in real time, finding the closest available driver in milliseconds, computing ETAs on live traffic graphs, and dynamically pricing rides based on supply-demand signals — all while maintaining sub-second response times globally.

Md Sanwar Hossain April 6, 2026 20 min read System Design

1. System Architecture Overview

A ride-hailing platform consists of several interconnected services that must collaborate in real time with hard latency requirements. The core services are:

• Location Service: Ingests driver GPS updates and maintains the current position of every active driver. The most write-intensive service in the system.
• Matching Service: Given a rider's pickup location, finds the best available driver using geospatial queries and a scoring function.
• Trip Service: Manages the trip lifecycle state machine from request to completion. The source of truth for trip status.
• Pricing Service: Computes base fare and surge multiplier per trip at the time of booking.
• Payment Service: Pre-authorizes card at trip start, captures final amount at completion.
• Notification Service: Delivers real-time updates to driver and rider apps via WebSocket and push notifications.
• Maps/Routing Service: Computes ETAs, turn-by-turn navigation, and route optimization.

2. Real-Time Driver Location Tracking

The location service is the most write-intensive component. Uber's driver app sends GPS updates every 4 seconds. With 1 million active drivers globally, that's 250,000 writes per second. The design must handle this without falling behind.

Adaptive Location Update Frequency

Not all drivers need the same update frequency. The app adapts based on trip state:

• Driver available (no trip): Update every 5 seconds. Rider doesn't need real-time precision.
• Driver en route to pickup: Update every 2 seconds. Rider watches the car approach on map.
• During active trip: Update every 1 second. Turn-by-turn navigation and fare metering require accuracy.
• Driver offline: No updates. Zero cost.

Location Write Path

# Driver location update flow
Driver App → WebSocket gateway → Location Service API
                                         │
                         ┌───────────────┴───────────────┐
                         ▼                               ▼
              Redis GeoSet (hot)              Kafka topic "location-updates"
              GEOADD drivers                      │
              {lat, lng, driverId}                ▼
                         │                  Stream processor
                         │                  (Flink/Kafka Streams)
                         ▼                  - Enriches with city/zone
              Nearby driver queries          - Writes to geospatial DB
              answered in O(log N)           - Updates surge pricing engine

3. Geospatial Indexing: H3 vs S2 Cells

The core challenge: given a rider at (lat, lng), find all available drivers within a 3km radius in under 10ms. Brute-force comparison of millions of driver coordinates is too slow. The solution: hierarchical geospatial cell indexing.

H3 Hexagonal Hierarchy (Uber's Choice)

Uber built and open-sourced H3, a hexagonal hierarchical geospatial indexing system. The globe is divided into hexagonal cells at 16 resolution levels. At resolution 9, each hexagon is approximately 0.1 km² — the right granularity for driver density in urban areas.

• Index drivers: Convert each driver's (lat, lng) to an H3 cell ID at resolution 9. Store as a Redis Set: SADD h3:cell:{cellId} driverId.
• Query: Convert rider's position to H3 cell ID. Get the "ring" of neighboring cells (k-rings) around it. Query Redis for all driver IDs in those cells.
• Advantage of hexagons: Unlike square grids, hexagons have equal distance from center to all 6 neighbors. This eliminates corner-proximity distortion and gives a more uniform "1-ring = 1km radius" approximation.

S2 Geometry (Google's Choice)

Google Maps and many geospatial systems use S2 — a library that maps the sphere surface to a space-filling Hilbert curve, allowing spatial regions to be represented as ranges of 64-bit integers. S2 cells are squares at each level. For a ride-hailing system, you can store driver IDs in a sorted set indexed by S2 cell ID. Range queries on the sorted set retrieve drivers in nearby cells efficiently. Lyft uses S2 for this purpose.

4. Driver Matching Engine

The matching engine must find the optimal driver for each rider request within a few hundred milliseconds. Simple nearest-distance matching is insufficient — a driver 0.3km away stuck in traffic may have a worse ETA than one 0.8km away on a clear road.

Matching Scoring Function

Each candidate driver is scored as a weighted combination of:

• ETA to pickup (highest weight, ~60%): Computed using live traffic data. The single most important factor for rider satisfaction.
• Driver rating (~15%): Average rating over last 500 trips. Prevents assigning poor-experience drivers to premium riders.
• Acceptance rate (~10%): Drivers who frequently decline requests reduce system efficiency. Penalize low-acceptance drivers.
• Ride type compatibility (~10%): UberX driver cannot accept UberXL request.
• Fairness/income equity (~5%): Among equally-scored drivers, prefer the one with fewer rides today to distribute income fairly.

Batched Global Matching vs Greedy Local Matching

Two approaches to matching at scale:

• Greedy local matching: Each rider request immediately finds the best local driver. Simple, low latency, but can lead to suboptimal global outcomes (two riders 100m apart both assigned the same distant driver instead of each getting a nearby one).
• Batched global matching (Uber's approach in dense areas): Accumulate all rider requests within a 500ms window. Run a batch bipartite matching algorithm (Hungarian method or similar) to globally optimize total ETA. Increases latency by 500ms but reduces total vehicle-miles driven by 10–15% in dense cities.

5. Trip State Machine

The trip lifecycle is modeled as a state machine with strict transition rules. Each transition is idempotent and persisted to PostgreSQL with an event log in Kafka for auditability.

REQUESTED ──► MATCHING ──► DRIVER_ASSIGNED ──► DRIVER_EN_ROUTE
                                                       │
                                              ◄── CANCELLED (by rider or driver)
                                                       │
                                              DRIVER_ARRIVED
                                                       │
                                              TRIP_IN_PROGRESS ──► COMPLETED
                                                       │
                                              CANCELLED (rare: during trip)

# Each transition:
# 1. Validates current state (prevents invalid transitions)
# 2. Updates trip record in PostgreSQL (optimistic lock on version column)
# 3. Publishes TRIP_STATE_CHANGED event to Kafka
# 4. Notification service consumes event → pushes to rider and driver

Idempotency is critical: if the driver app retries "I arrived" due to a network glitch, the system must not double-bill or create duplicate events. The trip service uses the current state check: if state is already DRIVER_ARRIVED, the repeated request is silently acknowledged without re-processing.

6. Surge Pricing Algorithm

Surge pricing (dynamic pricing) serves a dual purpose: it incentivizes more drivers to come online (supply-side response) and reduces demand during peak periods by raising prices. The algorithm must react in near-real-time and be computed per geographic zone.

Surge Multiplier Calculation

Each H3 cell (or a cluster of cells forming a "surge zone") is evaluated every 30 seconds:

# Surge multiplier formula (piecewise linear)
demand = open_ride_requests_in_zone (last 5 min)
supply = available_drivers_in_zone

ratio = demand / max(supply, 1)

if ratio < 0.5:
    multiplier = 1.0   # No surge
elif ratio < 1.0:
    multiplier = 1.0 + (ratio - 0.5) * 1.2  # Linear ramp
elif ratio < 2.0:
    multiplier = 1.6 + (ratio - 1.0) * 0.8  # Slower ramp
else:
    multiplier = min(2.4 + (ratio - 2.0) * 0.2, 5.0)  # Cap at 5x

# Round to nearest 0.1 for display clarity

Surge Zone Architecture

The surge engine runs as a stream processing job (Kafka Streams or Flink) consuming the location-updates and ride-requests topics. It maintains a sliding 5-minute window of demand/supply per H3 cell, computes multipliers, and writes results to Redis. When the pricing service needs the current surge for a rider's zone, it reads from Redis in <1ms. Surge zones are persisted to PostgreSQL for fare auditing (regulators require price records for each trip).

7. Payment & Fare Calculation

The payment flow uses a two-phase approach to handle the case where the final fare is unknown at trip start (the rider doesn't know exactly how far they'll go or how long it will take).

• Pre-authorization: When the ride is booked, pre-authorize 120% of the estimated fare on the rider's card. This reserves funds without charging. The authorization hold typically expires in 7 days.
• Fare metering during trip: The trip service calculates fare in real time based on distance traveled (from GPS track) × per-km rate + time elapsed × per-minute rate + base fare + surge multiplier.
• Final capture: When the trip status reaches COMPLETED, the payment service charges the exact final fare (up to the pre-auth amount) and releases the remainder. The rider gets a receipt push notification and email.
• Driver payout: Settled to driver's bank account weekly (or via Uber's "Instant Pay" debit card for daily settlement).

8. Real-Time Notifications & Messaging

Both rider and driver need real-time updates throughout the trip. The notification architecture uses a tiered approach:

The WebSocket gateway runs as a stateful service. Each connection is maintained by a specific gateway node. The notification service publishes events to Kafka; the gateway service has a consumer that routes messages to the correct WebSocket connection. For cross-node routing (event for user connected to node B arrives at node A's consumer), a Redis Pub/Sub channel broadcasts the message to all nodes — the correct node with the active connection delivers it.

9. Maps & ETA Calculation

ETA accuracy is a critical driver of rider satisfaction. Showing "3 minutes" and the driver arriving in 9 minutes destroys trust. The ETA engine must incorporate live traffic conditions, not just static road graphs.

Routing Pipeline

• Road graph: OpenStreetMap data (or proprietary) preprocessed into a directed weighted graph. Edges have base traversal time. The full graph for a major metro is ~5M nodes and ~12M edges — fits in memory on a routing server.
• Dijkstra / A* with live traffic: Edge weights are updated in real time using GPS traces from active drivers (they are anonymously used as traffic probes). An ML model predicts travel time per road segment for the next 15 minutes.
• Caching: ETA between frequently queried origin-destination pairs (airport to downtown, stadium to transit hub) is precomputed and cached in Redis with a 5-minute TTL. ~80% of ETAs can be served from cache during peak events.

10. Fault Tolerance & Global Scale

Uber operates in 10,000+ cities across 70 countries. The architecture must handle regional outages without global impact.

Cell-Based Regional Isolation

Uber's architecture partitions the world into geographic cells. Each cell (typically covering a metro area) runs its own instance of the location, matching, and trip services. A cell failure (e.g., AWS us-east-1 outage) affects only the cities in that cell — other regions continue operating normally. Cell boundaries are designed so no major metro spans two cells, preventing cross-cell coordination during failures.

Graceful Degradation

11. Capacity Estimation & Conclusion

A ride-hailing system is one of the most technically rich distributed system design problems because it touches every major distributed systems concept: real-time data streams, geospatial indexing, state machines, event-driven architecture, payment processing, and real-time communications — all under strict latency requirements. The H3 geospatial index and the two-phase matching approach are the most commonly tested concepts in system design interviews for this domain.

Md Sanwar Hossain

Software Engineer · Java · Spring Boot · Microservices · System Design

All Posts