Interactive system design

How do ride-hailing apps show live driver locations?

Follow a GPS update from a driver's phone through location services to a rider's map, then model the message rate at different fleet sizes.

Explore the flow

One trip, fresh updatesillustrative

Driver GPS

Location service

Rider map

A marker shows the newest received location—not a guarantee of perfect, instantaneous GPS.

Important: This is an illustrative scalable architecture based on common distributed-systems patterns. It is not confirmed Uber internal architecture. GPS accuracy, network delay, permissions, and update cadence mean a displayed location is never guaranteed to be exact or instantaneous.

Architecture flow

From a GPS fix to a rider's screen

Each service can scale independently. Geospatial routing limits distribution to interested riders instead of broadcasting every driver update to every user.

Driver phone

The app reads coordinates, timestamp, and accuracy from the device location service. Sampling can adapt to trip state and movement.

Ingestion gateway

A service authenticates updates, validates their shape and freshness, and absorbs a large stream of small messages.

Location views

A fast latest-position view serves current coordinates; a geospatial index helps identify drivers in nearby cells.

Realtime routing

Route updates to riders who need them for an active trip or an appropriate nearby area, not to every client.

Rider map

The app displays the newest received point and can animate between points. Animation does not make the GPS reading more exact.

Accuracy and timestamp travel with a point

Stale updates can be detected and surfaced

Delivery is scoped to relevant trip or map viewers

Change the inputs

Location update-rate simulator

Estimate how many small location messages the ingestion layer receives. This simplified model assumes every active driver sends an update at a steady interval.

Active drivers1,000,00010,0005,000,000Update interval3 sec1 second10 secondsApprox. message size200 bytes100 bytes1,000 bytes

Payload estimate is before protocol overhead, retries, encryption, replication, or burst headroom. Real update rates can vary by speed, connectivity, and trip state.

Estimated steady-state ingress

333,333.3updates / sec

Scale indicator relative to 1,000,000 updates / second

Payload ingress

533.3 Mbps

before overhead

Mean point age

~1.5 sec

ideal periodic sampling

Updates per day

28,800,000,000

if rate is steady

Mean point age assumes uniformly timed updates and no delivery delay. Network lag and missing fixes add staleness; production capacity requires measured traffic and headroom.

Getting the map right

Fresh is not the same as exact

GPS has uncertainty: coordinates include accuracy limits and can drift, especially indoors or among tall buildings.
Updates have latency: sampling, upload, processing, and delivery all add delay.
Maps can interpolate: smooth motion between points improves presentation but does not reveal the device's true position between GPS fixes.
Staleness matters: timestamps and health monitoring help distinguish a fresh location from a disconnected or backgrounded app.

Diagram source

Mermaid flowchart

Copy this source into a Mermaid-compatible renderer to edit or share the system flow.

flowchart LR
  D[Driver app GPS] --> U[Location update]
  U --> I[Ingestion gateway]
  I --> V[Authenticate + validate]
  V --> L[Latest-location store]
  V --> G[Geospatial index]
  L --> S[Trip / nearby subscriptions]
  G --> S
  S --> R[Realtime delivery]
  R --> P[Rider app]
  P --> M[Map marker interpolation]
  I --> O[Metrics + stale-location detection]