Uber System Design: The Problem

You tap "Request" and a few seconds later a driver is assigned. Behind that tap, Uber has to answer a hard question continuously, for an entire city at once: which of the thousands of moving cars should go to which of the thousands of waiting riders?

Both sides move. Drivers send fresh GPS positions every few seconds, riders appear anywhere, and the best match depends on roads and traffic, not straight-line distance. This post explains how Uber solves it, based on what its engineers have published and presented, plus the standard interview design.

🎯 Quick Answer (30-Second Read)

  • Drivers stream their location every few seconds to Uber's servers.
  • The map is split into cells (Google's S2 cells in early dispatch, later Uber's own hexagonal H3 grid) so "find cars near me" becomes a fast lookup, not a scan of every car.
  • DISCO, Uber's dispatch system, matches riders and drivers using ETA (estimated time to arrive), not just distance, and can consider drivers who are about to finish a trip.
  • Surge pricing compares demand and supply per area, which is where hexagon cells help.
  • A trip is a state machine: requested → matched → arriving → on trip → completed.

Requirements (Interview Framing)

Functional
Riders request rides and see nearby cars. Drivers go online and accept trips. Live tracking during the trip. Fare estimate, payment and ratings.
Non-functional
Matching in seconds. Handle a huge stream of location writes. Never assign one driver to two riders. Keep working when a data centre fails.

High-Level Architecture

flowchart TB R["📱 Rider app"] --> GW["API gateway"] D["🚗 Driver app"] -->|"GPS every few seconds"| LOC["Location service"] LOC --> GEO[("Geospatial index
cars by map cell")] GW --> DEM["Demand service
ride requests"] DEM --> DISCO["DISCO dispatch
matching"] GEO --> DISCO ETA["ETA service
road graph + traffic"] --> DISCO DISCO -->|"trip offer"| D DISCO --> TRIP[("Trip service
state + history")] GEO --> SURGE["Pricing / surge
demand vs supply per cell"] DEM --> SURGE TRIP --> PAY["Payments"]
Component Job
Location service Receives the stream of driver GPS updates
Geospatial index Keeps "which cars are in which cell" up to date
Demand service Handles ride requests from riders
DISCO (dispatch) Decides which driver gets which request
ETA service Predicts travel time on real roads
Pricing Calculates fares and surge per area
Trip service Tracks every trip's state and stores history

Step 1: Location Updates, a Firehose of Writes

Every online driver's app sends its position every few seconds. Multiply by every active driver in every city, and location becomes the system's biggest write load. Engineers described a goal of handling a million geospatial writes per second for the index.

Key design choices:

  • Keep the latest position in memory. For matching, only the current location matters. Full history goes to cheaper storage for analytics.
  • Overwrite, don't append. Each update replaces the driver's last position.
  • Shard by area. Each map cell (or group of cells) is owned by a server, so updates spread across machines.

Step 2: Geospatial Indexing, Splitting the Map Into Cells

"Find drivers within 2 km" is slow if you check every car. Instead, the map is divided into cells, each with an ID. To find nearby cars, look up the rider's cell and its neighbours.

S2
Google's library of square-ish cells on a sphere, used in Uber's early dispatch system
H3
Uber's hexagonal grid, open-sourced in 2018, used for pricing, dispatch and analysis
16
H3 resolutions, each cell about 1/7 the area of the level above

Why hexagons? Every neighbour of a hexagon is the same distance from its centre. With squares, diagonal neighbours are farther than side neighbours. That makes hexagons cleaner for "how much demand is around here?" calculations like surge pricing. A sphere can't be covered with hexagons alone, so H3 includes 12 pentagons placed where they rarely matter.

Step 3: Matching With DISCO

sequenceDiagram participant R as Rider participant DM as Demand service participant DC as DISCO participant G as Geo index participant E as ETA service participant D as Driver R->>DM: Request ride (pickup point) DM->>DC: New demand DC->>G: Cars in nearby cells? G-->>DC: 12 candidate drivers DC->>E: Road ETA for each candidate E-->>DC: ETAs (traffic-aware) DC->>D: Offer trip to best driver D-->>DC: Accept DC-->>R: Driver assigned, 4 min away

What makes matching smarter than "nearest car":

  • ETA, not distance. A car 500 m away across a river or a one-way system may be slower than one 1 km away. Uber's engineers described using ETAs based on historical travel data.
  • Drivers finishing a trip. DISCO can consider a car that's about to drop someone off nearby and project its route forward.
  • Whole-city optimisation. Matching each request greedily to the closest car can leave other riders stranded. Looking at several requests together gives a better overall result.
  • No double-booking. Assigning a driver must be atomic, so two requests can never grab the same car at once.

Step 4: The Trip as a State Machine

stateDiagram-v2 [*] --> Requested Requested --> Matched: driver accepts Requested --> Cancelled: no driver / rider cancels Matched --> Arriving Arriving --> OnTrip: rider picked up Arriving --> Cancelled OnTrip --> Completed: drop-off Completed --> Paid: payment captured Paid --> [*] Cancelled --> [*]

Modelling trips as explicit states makes failures manageable. If a phone loses network mid-trip, the server still knows the trip is "OnTrip" and can resume tracking when it reconnects.

Step 5: Surge Pricing

When ride requests in an area outpace available drivers, prices rise there. That does two things: it nudges some riders to wait, and it pulls drivers toward busy areas. The system needs demand and supply per cell, updated every few minutes, which is exactly what the geospatial index and request stream provide.

How Uber's Architecture Evolved

Key takeaway: early on, Uber ran dispatch as stateful Node.js services connected by Ringpop, its own library for spreading work across a cluster. As it grew, it split dispatch into separate services for supply, demand, geospatial and matching. The core ideas (cells, ETA-based matching, trip states) stayed.

Frequently Asked Questions

How does Uber find nearby drivers so quickly?

Uber divides the map into cells with IDs and keeps an up-to-date index of which drivers are in each cell. Finding nearby drivers means looking up the rider's cell and its neighbours instead of checking every car, then ranking those candidates by estimated arrival time.

What is Uber H3?

H3 is Uber's open-source hexagonal grid system for the whole planet, released in 2018. It has 16 resolutions, each cell about one seventh the area of its parent. Uber uses it for pricing, dispatch and analysing spatial data, and many other companies now use it too.

How do you design Uber in a system design interview?

Cover the location update stream, a geospatial index (cells such as geohash, S2 or H3), a matching service that uses ETAs, a trip state machine, and how you prevent double-booking. Then discuss scaling: sharding by area, keeping current locations in memory, and handling surge pricing.

Conclusion

Uber's system comes down to a few ideas: stream driver locations into a cell-based index, match riders using real road ETAs instead of distance, treat every trip as a state machine, and price by comparing demand and supply per area. The same pattern powers food delivery, quick commerce and logistics apps everywhere.

Sources

Last verified: 14 October 2026.

Related reads: How Swiggy Built a Logistics Network Without Addresses · Consistent Hashing Explained · Load Balancer Explained · WhatsApp System Design

I write about system design and how real products are built. Follow on LinkedIn or X, or invite me to speak.