System Design Lab

Ride matching is bound by ingesting high-frequency driver GPS and answering nearest-driver queries fast, not by request volume.

Tune how many drivers are online, how often each one reports GPS, the ride-request rate, the search radius, and how many cities you serve. The design moves from one service to a dedicated location-ingest path, an in-memory geospatial index for nearest-driver queries, a durable trip-state store, and per-geo sharding with surge pricing.

Read the full tutorial

Guided walkthrough

Reason about it one step at a time

Normal evolution scenarios

Click left to right for the intended demo path. Each card changes the workload inputs.

Workload

These are inputs, not preset architecture stages.

Active drivers Drivers currently online and reporting GPS. Each one is a continuous write stream. GPS update frequency How often each driver reports a new location. This sets the ingest write rate. Ride requests Riders asking to be matched. Each one triggers a nearest-driver geo query. Search radius How far to look for available drivers. Wider radius scans more index cells per query. Drivers per cell Density of drivers in a geohash/S2 cell. Hot dense cells cost more per query. Cities / regions Independent geographies served. Each can be a natural shard boundary. Match latency target Budget to find candidate drivers and return a match to the rider. Surge pricing Compute demand/supply ratio per area to raise prices; runs as its own engine. ETA / route prediction Predict arrival and route per candidate; adds compute to every match.

Recommended shape

Current architecture path

Clients

Driver app reports its location every few seconds while online

Rider app asks to be matched with the nearest available driver

Ingest / gateway

API gateway authenticates riders and routes match requests to the matching service

Location ingest absorbs the firehose of driver GPS updates and feeds the geo index

Geo + matching

Geo index keeps live driver positions in geohash/quadtree/S2 cells for nearest queries

Matching service queries the index for candidates and pairs a rider to a driver

Trip state

Trip-state store durably tracks each trip from requested to matched to en route to complete

Geo shards partitions drivers and trips by geography so each region scales independently

Pricing / analytics

Surge engine computes per-area surge multipliers off the hot matching path

Event stream collects trip and location events for analytics and ML offline

Bottlenecks

Location write throughput

Geo-query load

Geo-index memory

Matching + trip-state QPS

Cross-city / shard pressure

Why this changes

Decision tradeoffs

Location ingest path

Geospatial index

Matching service

Trip-state store

Surge pricing engine

Shard by city / geo

Source-backed rules

These are the durable system-design claims behind the model. The exact slider thresholds are deliberately labeled as teaching assumptions.

Verified rule

Uber matches riders to drivers using S2 geospatial cells

Uber indexes the world with hierarchical cells (H3, building on Google S2) so nearest-driver lookups become bounded scans over a small set of cells.

Uber Engineering

Verified rule

Geohashing turns proximity search into prefix range scans

Encoding lat/long as a geohash lets nearby points share a prefix, so a radius query becomes a small set of in-memory sorted-set range reads.

Redis Docs

Verified rule

High-frequency location ingest is a write-heavy streaming problem

A continuous flood of per-driver GPS events is best absorbed by a partitioned log that decouples ingest from the index and downstream consumers.

Apache Kafka

Verified rule

Quadtrees answer 2D nearest-neighbour queries efficiently

A quadtree recursively subdivides space so a region query only visits the cells that overlap the search area instead of every point.

Wikipedia

Teaching assumptions

Location ingest write rate is modeled as active drivers times GPS update frequency; real systems batch and dedup updates.
Single-node ingest, geo-query, and trip-state budgets are conservative teaching numbers, not vendor limits.
Geo-query cost grows with search radius and cell density; the in-memory index memory scales with active drivers.