Design Uber-Style Ride Hailing

A reference design for a ride-hailing platform that has to match riders with drivers in seconds, track millions of vehicles in near-real-time, predict ETAs at single-digit-millisecond latency, and price rides dynamically across thousands of micro-markets. This article works through the architecture, the data model, the matching algorithm, and the operational levers a senior engineer should be able to defend in a design review — grounded in Uber’s published engineering work wherever the public record allows, with explicit hedging where it doesn’t.

Thesis

Three problems sit at the centre of any ride-hailing platform, and the rest of the system mostly exists to feed them:

1. Spatial indexing. Find candidate drivers near a pickup in milliseconds, even when there are millions of them moving in real time.
2. Dispatch optimisation. Pick which driver gets which rider, optimising the whole batch rather than each request in isolation.
3. Dynamic pricing. Move price up and down per micro-market to clear demand against supply without scaring the rider or whip-sawing the driver.

Uber’s published architecture lands on three opinionated answers: H3 hexagonal cells for spatial indexing, batch matching (DISCO) on a bipartite graph weighted by ETA, and a hybrid physics-plus-ML ETA model (DeepETA) that runs at p95 ≈ 4 ms. We’ll work through each, then assemble the rest of the system around them.

Mental model

Before the deep dive, the smallest set of concepts the rest of the article assumes:

• H3 cell. A hexagonal tile of the Earth at one of 16 hierarchical resolutions (0–15). Every lat/lng resolves to exactly one cell at each resolution. We mostly use res-9 cells (~0.105 km², edge ~174 m) for driver indexing and res-7 cells (~5.16 km², edge ~1.22 km) for surge.
• k-ring. The set of cells within k “hops” of a center cell. gridDisk(cell, k) is the H3 primitive; k=1 returns the 6 immediate neighbours.
• DISCO. Uber’s dispatch service. It buffers ride requests for a short window, builds a bipartite graph of riders × candidate drivers weighted by ETA, then solves the assignment globally instead of greedily picking the nearest driver per request.
• DeepETA. A small neural network that post-processes the routing engine’s “naive” ETA, predicting a residual that the routing engine couldn’t capture (traffic, time-of-day, route oddities).
• Schemaless / Docstore. Uber’s append-only, MySQL-backed sharded datastore family. Schemaless was the original (2014–2016); it has since evolved into Docstore, which adds Raft consensus and stricter consistency. Throughout this article, “Schemaless/Docstore” means the same family.

Requirements

Functional

Non-functional

Scale estimation

Use Uber’s public 2024 numbers as the anchor point. Q4 2025 figures are higher; the 2024 anchor gives us round numbers that are easy to reason about.

• Trips: 11.27B trips in 2024 ≈ ~30M trips/day on average; Q4 2024 averaged ~33M/day across the platform¹.
• Monthly active platform consumers (MAPCs): 171M in Q4 2024¹; over 200M in Q4 2025².
• Drivers + couriers on the platform: 6.8M monthly in Q4 2024¹. The “concurrent online” number is materially smaller — call it 1–3M drivers globally at peak as a planning assumption.

Derived load envelope:

• Location updates: 1–3M concurrent drivers × 1 ping every ~4 s → roughly 0.25M–0.75M updates/sec sustained; bursts to ~1M+/sec³. Design for a 10⁶/sec ceiling.
• Ride requests: ~30M/day → ~350 RPS average, ~1,500 RPS peak.
• Nearby-driver / fare-estimate queries: 5–10× ride requests; users browse before they book.
• Kafka: Uber’s published Kafka throughput is in the trillions of messages and multiple petabytes per day⁴. The location topic is a meaningful fraction of that.

Storage:

• Trip record: ~5 KB metadata + ~20–50 KB polyline → 25–55 KB per trip → ~1–1.5 TB/day at 30M trips.
• Hot location window: 1M concurrent drivers × ~1 KB latest pos × 30 s TTL is trivial in cache; the firehose is in Kafka.

Design paths

Three viable architectures, sorted by where they typically appear:

Path A: Geohash + greedy matching

Best for: MVPs and single-city deployments at moderate scale (sub-100K concurrent drivers), where 5+ second matches are acceptable.

• Geohash string indexing (e.g. 9q8yyk for SF downtown).
• Each request matched immediately to the nearest available driver.
• No batching, no global optimisation.

Lyft’s earliest matching system was geohash-flavoured and evolved similarly⁵.

Path B: H3 + batch optimisation (chosen)

Best for: Dense urban markets, global scale, and any product where total wait time is a top KPI.

• H3 res-9 hexagonal cells for the live driver index.
• Buffer requests in short windows (illustratively 100–200 ms) and solve assignment as a bipartite-matching problem.
• Edge weights = predicted ETA, not Euclidean distance.

This is the path Uber’s engineering team publicly endorses and the one we’ll build out below.

Path C: Quadtree + real-time streaming

Best for: Markets with highly variable density (sparse suburbs vs. dense cores) where adaptive cell size matters more than uniformity.

• Quadtree adapts cell size to local density.
• Stream processing (Flink / Samza) emits matches continuously rather than in batches.

Path comparison

The rest of the article assumes Path B.

High-level design

Service boundaries

The system splits into seven services that each have a single responsibility and a well-defined SLO:

Ride Service

Owns the trip lifecycle from request to completion.

• Validates pickup/destination, checks surge, creates the trip record.
• Drives the trip state machine: REQUESTED → MATCHED → DRIVER_ARRIVING → DRIVER_ARRIVED → IN_PROGRESS → COMPLETED (with CANCELLED from most states).
• Handles cancellations and applies fees/policies.
• Persists trip records for history, analytics, and disputes.

Matching Service (DISCO)

The dispatch engine that assigns riders to drivers.

• Receives ride requests from Ride Service.
• Queries Location Service for nearby available drivers.
• Queries Routing/ETA Service for ETA per candidate.
• Builds a bipartite cost matrix and solves the assignment problem.
• Dispatches the chosen driver and flips driver state to DISPATCHED.

Location Service

Tracks real-time driver positions at high write throughput.

• Ingests GPS pings every 4–5 s from the Driver App.
• Stores the current position in Redis indexed by H3 cell.
• Maintains a rolling hot window for trajectory.
• Publishes location changes to Kafka for downstream consumers (matching, surge, fraud).
• Supports spatial queries: “drivers within k-rings of this H3 cell, status AVAILABLE.”

Pricing Service

Calculates fares and surge.

• Base fare (distance, time, vehicle type).
• Surge multiplier lookup per H3 cell (refreshed on the order of minutes).
• Upfront pricing — show the fare before the rider commits.
• Promo / discount application.
• Final fare reconciliation if the actual route differs from the estimate.

Routing & ETA Service

Provides navigation and time estimates.

• Road-network graph (OpenStreetMap or licensed equivalent).
• Real-time traffic ingestion.
• Hybrid ETA: a routing engine computes the “naive” baseline; DeepETA predicts the residual⁶.
• Turn-by-turn navigation for the Driver App.

Payment Service

Owns financial transactions.

• Tokenised payment methods (no raw card numbers).
• Charges on trip completion.
• Split payments and receipts.
• Driver payout aggregation.
• Fraud detection integration.

Request flow: the happy path

Trip state machine

The Ride Service is the source of truth for the state machine. Most user-facing surfaces are just projections of the current state.

State transitions are written as new “cells” in Schemaless/Docstore (append-only), so any auditing or reconstruction question can be answered by replaying the cells in added_id order.

The orchestration around the state machine — driver-arrived timers, no-show fees, payment retries, refund/compensation flows when a trip cancels mid-charge — is well-suited to a durable workflow engine. Uber built Cadence for exactly this class of long-running, fault-tolerant business logic; the original authors later forked it as Temporal⁷. Modeling each trip as a Cadence/Temporal workflow keeps the application code a straightforward sequence of awaits while the engine owns persistence, retries, signal delivery, and crash recovery — so a worker reboot mid-trip resumes from the last checkpoint without dropping the rider.

Real-time location tracking

The 30 s TTL on the Redis entry doubles as a presence signal: a driver that stops sending pings disappears from the index automatically without an explicit “offline” message.

API design

Ride request

Endpoint: POST /api/v1/rides

Show 3 hidden lines45// Request body6{7  "pickup": {8    "latitude": 37.7749,9    "longitude": -122.4194,10    "address": "123 Market St, San Francisco, CA"11  },12  "destination": {13    "latitude": 37.7899,14    "longitude": -122.4014,15    "address": "456 Mission St, San Francisco, CA"16  },17  "vehicleType": "UBER_X",18  "paymentMethodId": "pm_abc123",19  "riderCount": 1,20  "scheduledTime": null21}

Response (201 Created):

Show 5 hidden lines6    "longitude": -122.4194,7    "address": "123 Market St, San Francisco, CA"8  },9  "destination": {10    "latitude": 37.7899,11    "longitude": -122.4014,12    "address": "456 Mission St, San Francisco, CA"13  },14  "estimate": {15    "fareAmount": 1850,16    "fareCurrency": "USD",17    "surgeMultiplier": 1.2,18    "distanceMeters": 2100,19    "durationSeconds": 48020  },21  "etaToPickup": null,22  "driver": null,23  "vehicle": null,24  "createdAt": "2024-01-15T14:30:00Z"25}

Error responses:

Rate limits: 10 requests/minute per user (prevents spam requests and click-fatigue retries).

Driver location update

Endpoint: WebSocket wss://location.uber.com/v1/driver

1// Client → Server (every 4-5 seconds)2{3  "type": "LOCATION_UPDATE",4  "payload": {5    "latitude": 37.7751,6    "longitude": -122.4183,7    "heading": 45,8    "speed": 12.5,9    "accuracy": 5.0,10    "timestamp": 170532900000011  }12}1314// Server → Client (acknowledgment)15{16  "type": "LOCATION_ACK",17  "payload": {18    "received": 170532900012319  }20}

Why WebSocket, not HTTP polling:

• Bidirectional — the same socket pushes ride requests to the driver instantly.
• Persistent connection amortises TCP/TLS handshake cost over thousands of pings.
• Battery efficient compared to repeated HTTP requests.
• Sub-second latency is required for the rider to see smooth pin movement.

Get nearby drivers (fare-estimate screen)

Endpoint: GET /api/v1/drivers/nearby

Show 3 hidden lines4      "driverId": "driver_xyz",5      "latitude": 37.7755,6      "longitude": -122.418,7      "heading": 90,8      "vehicleType": "UBER_X",9      "etaSeconds": 18010    },11    {12      "driverId": "driver_abc",13      "latitude": 37.774,14      "longitude": -122.42,15      "heading": 270,16      "vehicleType": "UBER_X",17      "etaSeconds": 24018    }19  ],Show 3 hidden lines

Surge price

Endpoint: GET /api/v1/surge

1{2  "multiplier": 1.5,3  "reason": "HIGH_DEMAND",4  "h3Cell": "892a100d2c3ffff",5  "expiresAt": "2024-01-15T14:40:00Z",6  "demandLevel": "VERY_HIGH",7  "supplyLevel": "LOW"8}

The expiresAt is non-negotiable. If the rider takes longer than that to confirm, the client must re-fetch the price; otherwise we either undercharge (rider expects 2×, supply has improved to 1×) or generate disputes (rider expects 1×, supply has dropped and we now want 2×).

Data modelling

Trip records — Schemaless / Docstore

Uber’s trip store started as Schemaless: a sharded, append-only datastore on top of MySQL. Every “cell” is immutable; updates write a new cell with a higher ref_key. The system was described in detail in 2016 and has since evolved into Docstore, which adds Raft consensus, stricter consistency, and an integrated cache (CacheFront) that serves over 150M reads/sec. The data model below uses the Schemaless shape because it’s the cleanest way to model an append-only trip lifecycle; Docstore is a backwards-compatible superset.

Show 5 hidden lines67CREATE TABLE trips (8    added_id    BIGINT AUTO_INCREMENT PRIMARY KEY,  -- total ordering, linear writes9    row_key     BINARY(16) NOT NULL,                -- trip_id as UUID10    column_name VARCHAR(64) NOT NULL,11    ref_key     BIGINT NOT NULL,                    -- version12    body        MEDIUMBLOB NOT NULL,13    created_at  DATETIME NOT NULL,1415    INDEX idx_row_column (row_key, column_name, ref_key DESC)16);

Why this shape:

• Append-only writes keep the hot path linear and avoid in-place update contention on the MySQL primary.
• Time-travel is free — you can reconstruct any historical view of a trip by replaying cells up to a given added_id.
• Schema-flexible — new columns ship without ALTER TABLE.
• Sharded by row_key (4,096 logical shards in Uber’s setup) — all cells for a given trip live on the same shard.

Driver location — Redis with H3 indexing

The hot read path is “give me drivers within k-rings of cell X with status AVAILABLE.” Redis sorted sets are the right primitive: cell membership is a ZADD, neighbour expansion is a gridDisk lookup followed by N ZRANGEs.

1# Driver's current location (TTL = 30s; absent driver = offline)2SET driver:{driver_id}:location \3  '{"lat":37.7751,"lng":-122.4183,"h3":"89283082837ffff","heading":45,"speed":12.5,"status":"AVAILABLE","ts":1705329000}'4EXPIRE driver:{driver_id}:location 3056# H3-cell index (resolution 9 ≈ 100 m cells)7# Score = timestamp; lets us evict stale entries with ZREMRANGEBYSCORE8ZADD drivers:h3:89283082837ffff 1705329000 driver_1239ZADD drivers:h3:89283082837ffff 1705328995 driver_4561011# Status index for cheap filtering before a candidate set is materialised12SADD drivers:status:AVAILABLE driver_123 driver_45613SREM drivers:status:AVAILABLE driver_78914SADD drivers:status:ON_TRIP   driver_789

Why H3 resolution 9 (~100 m, edge ≈ 174 m):

• Fine enough to cut a city block into ~3–5 cells.
• Coarse enough that a city’s worth of cells fits comfortably in memory.
• A gridDisk of k=3 covers ~1 km radius, k=10 covers ~3 km — the band we actually search for nearby drivers.

Redis Cluster shards by key, so drivers:h3:{cell} distributes naturally; the GEOSEARCH/GEORADIUS family of commands is also on the table, but H3 makes the rest of the system (surge, analytics) easier and is worth the small extra effort over Redis’s built-in geohash scoring⁸.

Driver state — Cassandra

Driver profile and presence are write-heavy and tolerant of eventual consistency on reads — a good fit for a wide-column store with tunable consistency.

1-- Driver profile and operational state (high availability)2CREATE TABLE driver_state (3    driver_id            UUID,4    city_id              INT,5    status               TEXT,           -- OFFLINE, AVAILABLE, DISPATCHED, ON_TRIP6    vehicle_id           UUID,7    current_trip_id      UUID,8    last_location_update TIMESTAMP,9    rating               DECIMAL,10    total_trips          INT,11    acceptance_rate      DECIMAL,12    PRIMARY KEY ((city_id), driver_id)13) WITH CLUSTERING ORDER BY (driver_id ASC);1415-- Per-driver per-day location time series (write-heavy, TTL'd)16CREATE TABLE driver_locations (17    driver_id  UUID,18    day        DATE,19    timestamp  TIMESTAMP,20    latitude   DOUBLE,21    longitude  DOUBLE,22    h3_cell    TEXT,23    speed      DOUBLE,24    heading    INT,25    PRIMARY KEY ((driver_id, day), timestamp)26) WITH CLUSTERING ORDER BY (timestamp DESC);

• Partition by city keeps a market’s drivers co-located on a small number of nodes — fewer cross-coordinator scatter-gathers for “all drivers in SF.”
• Tunable consistency. Read at LOCAL_ONE for the hot path, write at LOCAL_QUORUM for durability. The “what’s this driver’s current trip?” question can tolerate a few hundred ms of replica lag.
• TTL on driver_locations keeps the hot keyspace bounded.

Database-by-workload matrix

Low-level design

H3 spatial indexing

H3 is Uber’s open-source hexagonal hierarchical spatial index. It tiles the Earth with hexagons (and exactly 12 pentagons per resolution) at 16 hierarchical levels.

Why hexagons over squares

1Square grid (geohash):           Hexagonal grid (H3):23+---+---+---+                    / \ / \ / \4| A | B | C |                   |   |   |   |5+---+---+---+    →              | A | B | C |6| D | X | E |                   |   |   |   |7+---+---+---+                    \ / \ / \ /8| F | G | H |                     |   |   |9+---+---+---+                     | D | E |1011Distances from X:                 Distances from X:12  - A,C,F,H: √2 (diagonal)          - all 6 neighbours: 1 (uniform)13  - B,D,E,G: 1 (cardinal)

Hexagons have 6 grid neighbours at uniform topological distance. Square cells have 4 cardinal + 4 diagonal neighbours at √2× the cardinal distance. The hexagonal uniformity matters for:

• Surge pricing — adjacent cells contribute equally to the gradient.
• Demand forecasting — spatial smoothing is unbiased across directions.
• Driver proximity — radius queries don’t get a √2 penalty along diagonals.

Earth-distance still varies cell-to-cell because H3 projects from an icosahedron — at any given resolution the largest cell is ~2× the area of the smallest. For latency-sensitive code that needs precise neighbour distance, prefer the H3 greatCircleDistance API (renamed from pointDist in v4) over the resolution’s average edge length.

Resolution table

Numbers from the H3 cell-stats table.

Operations in code

Show 8 hidden lines9// All cells within `k` rings of a center cell (k=1 → 6 neighbours, k=3 ≈ 1 km).10function getCellsInRadius(centerH3: string, radiusKm: number): string[] {11  // ~170 m per cell at res 912  const k = Math.ceil(radiusKm / 0.17)13  return h3.gridDisk(centerH3, k)14}1516// Find drivers within ~2 km of pickup. One Redis pipeline call per request.17async function findNearbyDrivers(18  pickupLat: number,19  pickupLng: number,20  radiusKm = 2,21): Promise<Driver[]> {22  const centerCell = locationToH3(pickupLat, pickupLng)23  const searchCells = getCellsInRadius(centerCell, radiusKm)2425  const pipeline = redis.pipeline()26  for (const cell of searchCells) {27    pipeline.zrange(`drivers:h3:${cell}`, 0, -1)28  }2930  const results = await pipeline.exec()31  const driverIds = new Set(results.flat().filter(Boolean))32  return fetchDriverDetails([...driverIds])33}

Matching algorithm (DISCO)

DISCO matches riders to drivers using batched optimisation rather than greedy nearest-driver assignment. Uber’s marketplace page explicitly contrasts the original “closest first” approach with the current batched matching that “considers all open requests and nearby drivers in a market and finds the best overall combination.”

Batch optimisation window

Show 10 hidden lines11  h3Cell: string12  lat: number13  lng: number14  etaSeconds: number // To pickup15}1617// Buffer ride requests for a short window before solving assignment.18class MatchingBatcher {19  private pendingRequests: RideRequest[] = []20  private batchInterval = 150 // ms — illustrative2122  constructor() {23    setInterval(() => this.processBatch(), this.batchInterval)24  }2526  addRequest(request: RideRequest) {27    this.pendingRequests.push(request)28  }2930  private async processBatch() {31    if (this.pendingRequests.length === 0) return3233    const requests = this.pendingRequests34    this.pendingRequests = []3536    const candidatesMap = await this.findCandidatesForAll(requests)37    const graph = this.buildBipartiteGraph(requests, candidatesMap)38    const assignments = this.solveAssignment(graph)3940    for (const { rideId, driverId, eta } of assignments) {41      await this.dispatchDriver(rideId, driverId, eta)42    }43  }44}

Solving the assignment

The classic textbook formulation: given N riders and M drivers with a cost matrix (predicted ETAs), find the assignment that minimises the total cost. The Hungarian algorithm gives an exact O(n³) solution; for production-scale batches with thousands of pairs, an auction algorithm or an approximation gives better latency for similar quality.

Uber doesn’t publish exactly which solver DISCO runs internally — the published material confirms the batched-bipartite framing without naming an algorithm. Treat the snippet below as a faithful textbook implementation, not as Uber’s literal code:

Show 5 hidden lines6  candidates: Map<string, DriverCandidate[]>,7): Assignment[] {8  const n = requests.length9  const allDrivers = new Set<string>()10  candidates.forEach(c => c.forEach(d => allDrivers.add(d.driverId)))11  const m = allDrivers.size12  const driverList = [...allDrivers]1314  const cost: number[][] = Array(n)15    .fill(null)16    .map(() => Array(m).fill(Infinity))1718  for (let i = 0; i < n; i++) {19    const rideCandidates = candidates.get(requests[i].rideId) ?? []20    for (const candidate of rideCandidates) {21      const j = driverList.indexOf(candidate.driverId)22      cost[i][j] = candidate.etaSeconds23    }24  }2526  // Hungarian: O(n³). Auction / relaxation: typically faster in practice.27  const assignments = hungarianAlgorithm(cost)2829  return assignments.map(([i, j]) => ({30    rideId: requests[i].rideId,31    driverId: driverList[j],32    eta: cost[i][j],33  }))34}

Why the batch window:

• < 50 ms — too few requests in the window to benefit from global optimisation.

• 300 ms — riders perceive the delay; you’ve spent latency budget without buying much more optimality.

• The 100–200 ms band is the typical engineering sweet spot in published write-ups; it’s an illustrative target, not a fixed Uber number.

ETA prediction (DeepETA)

DeepETA is a post-processing model: a routing engine produces a “naive” ETA from the road graph and live traffic, and DeepETA predicts a small residual that the routing engine couldn’t capture (intersections, detours, time-of-day patterns, vehicle-type biases). This separation is what lets the model be tiny enough to serve at p95 ≈ 4 ms and median ≈ 3.25 ms⁹, at hundreds of thousands of QPS — making it the highest-QPS model at Uber.

Architecture

1                    ┌─────────────────┐2                    │  Road Network   │3                    │  Graph (OSM)    │4                    └────────┬────────┘5                             │6    Pickup/Destination ──────┼──────────────┐7                             ▼              ▼8                    ┌─────────────────┐ ┌─────────────────┐9                    │ Routing Engine  │ │  DeepETA Model  │10                    │ (Dijkstra/A*)   │ │ (Linear Trans.) │11                    └────────┬────────┘ └────────┬────────┘12                             ▼                   ▼13                    Naive ETA (Y)        ML residual (R)14                             │                   │15                             └───────┬───────────┘16                                     ▼17                            Final ETA = Y + R

Implementation details worth knowing:

• The transformer is linear (not standard quadratic self-attention) to keep inference O(K·d²) rather than O(K²·d) in the number of features.
• A segment bias adjustment layer in the decoder offsets the prediction by request type (rideshare vs delivery vs reservations) so a single model can serve heterogeneous traffic without a multi-head decoder.
• Multi-resolution location embeddings with feature hashing keep the embedding table memory under control.
• The loss is an asymmetric Huber loss so the model can be trained for the mean (used for fares) or for a quantile (used for the user-facing ETA, where being early is worse than being late).

Feature shape

Show 5 hidden lines67  // Temporal features8  hourOfDay: number       // 0-239  dayOfWeek: number       // 0-610  isHoliday: boolean11  minutesSinceMidnight: number1213  // Traffic features14  currentTrafficIndex: number    // 0-1, free flow → gridlock15  historicalTrafficIndex: number // same time last week16  trafficTrend: number           // improving / worsening1718  // Route features19  distanceMeters: number20  numIntersections: number21  numHighwaySegments: number22  routingEngineETA: number       // physics-based baseline2324  // Weather (optional)25  precipitation: number26  visibility: number27}2829async function predictETA(features: ETAFeatures): Promise<number> {Show 4 hidden lines

Surge pricing engine

Surge balances supply and demand inside an H3 cell by raising the multiplier when there are too few drivers for too many requests. Uber doesn’t publish its exact formula, so the formula below is illustrative — it captures the shape (piecewise, capped, smoothed) of every surge engine in the wild.

Supply/demand calculation

Show 8 hidden lines9async function calculateSurge(cityId: string): Promise<Map<string, SurgeCell>> {10  const cells = new Map<string, SurgeCell>()11  const cityCells = getCityH3Cells(cityId, 7)1213  for (const h3Cell of cityCells) {14    const demandCount = (await redis.get(`demand:${h3Cell}:5min`)) ?? 01516    // Supply is indexed at res 9; expand to the res-7 footprint.17    const childCells = h3.cellToChildren(h3Cell, 9)18    let supplyCount = 019    for (const child of childCells) {20      supplyCount += await redis.scard(`drivers:h3:${child}:available`)21    }2223    const ratio = supplyCount > 0 ? demandCount / supplyCount : 1024    const multiplier = calculateMultiplier(ratio)2526    cells.set(h3Cell, {27      h3Cell,28      demandCount,29      supplyCount,30      multiplier,31      updatedAt: Date.now(),32    })33  }3435  return cells36}3738// Piecewise linear — illustrative shape, not Uber's exact function.39function calculateMultiplier(ratio: number): number {Show 5 hidden lines

Temporal smoothing

Raw 5-minute windows are noisy. Two layers of smoothing keep the multiplier stable enough to trust:

Show 5 hidden lines6  const ema = alpha * current + (1 - alpha) * previous78  // Hard cap on per-update delta — avoids "surge whip-saw"9  const maxDelta = 0.310  const delta = ema - previous11  if (Math.abs(delta) > maxDelta) {12    return previous + Math.sign(delta) * maxDelta13  }14  return ema15}

Two granularities, one product:

• Spatial. Driver index at res 9; surge at res 7. Surge that’s too granular (“2× here, 1.2× across the street”) confuses riders and creates arbitrage; res 7 (~5 km²) is roughly neighbourhood-sized.
• Temporal. Recompute every few minutes, smooth with EMA, cap per-update delta. The displayed multiplier in the rider app refreshes faster than the underlying compute.

Safety and fraud

Safety and fraud are not a single service — they’re cross-cutting checks layered onto the same event streams the marketplace already produces. Two flavours matter most for a ride-hailing platform:

• Account / payment fraud. Stolen-card use, account-takeover, promo abuse, collusive driver–rider pairs running fake trips for incentives. The signal lives in payments, login, device, and trip-completion events; the response is a real-time scoring service that can decline a ride request, force a step-up auth, or flag for manual review. Uber’s published platform of choice is Michelangelo for the model lifecycle and a dedicated risk-scoring service on the request hot path¹⁰.
• In-trip safety. Crash detection (sudden deceleration from on-trip telemetry), route deviation alerts, the “ride check” pattern Uber rolled out publicly¹¹, in-app emergency button with location handoff to a 911 RapidSOS-style dispatcher, and trusted-contact share-trip links. The ingestion path is the same Kafka location stream; the scoring path is a separate Flink job that fires alerts when a trajectory diverges from the planned route or accelerometer data crosses a crash threshold.

Two design heuristics are non-negotiable here. First, make every dollar-touching path idempotent — see the offline note above — so a retried charge or a doubled webhook never produces a duplicate transaction. Second, never let safety pipelines share a queue with billing: a backed-up surge-pricing job must not delay a crash-detection alert. Use separate Kafka topics, separate consumer groups, and separate on-call rotations.

Frontend considerations

Map rendering performance

Drawing 20+ driver pins that each move every 4–5 s is cheap if you batch updates and render to a canvas overlay; it’s catastrophic if you mutate DOM nodes per pin per tick.

Show 10 hidden lines11      this.rafId = requestAnimationFrame(() => this.render())12    }13  }1415  private render() {16    for (const update of this.pendingUpdates) {17      this.drivers.set(update.driverId, update)18    }19    this.pendingUpdates = []20    this.rafId = null2122    const ctx = this.canvas.getContext("2d")!23    ctx.clearRect(0, 0, this.canvas.width, this.canvas.height)2425    for (const driver of this.drivers.values()) {26      this.drawDriver(ctx, driver)27    }28  }2930  private drawDriver(ctx: CanvasRenderingContext2D, driver: DriverPosition) {31    const [x, y] = this.latLngToPixel(driver.lat, driver.lng)32    ctx.save()33    ctx.translate(x, y)34    ctx.rotate((driver.heading * Math.PI) / 180)Show 4 hidden lines

Real-time trip tracking state

The Ride Service is authoritative. The client is a projection; every WebSocket message moves the local state machine forward.

Show 5 hidden lines6  | "DRIVER_ARRIVING"7  | "DRIVER_ARRIVED"8  | "IN_PROGRESS"9  | "COMPLETED"10  | "CANCELLED"1112interface RideState {13  status: RideStatus14  ride: Ride | null15  driver: Driver | null16  driverLocation: LatLng | null17  etaSeconds: number | null18  route: LatLng[] | null19}2021function handleRideUpdate(state: RideState, message: WSMessage): RideState {22  switch (message.type) {23    case "DRIVER_ASSIGNED":24      return {25        ...state,26        status: "DRIVER_ASSIGNED",27        driver: message.driver,28        etaSeconds: message.eta,29      }3031    case "DRIVER_LOCATION":32      return {33        ...state,34        driverLocation: message.location,Show 11 hidden lines46        ride: { ...state.ride!, fare: message.fare },47      }4849    default:50      return state51  }52}

Offline handling

Riders in patchy coverage will lose connectivity mid-request. Queue locally, retry on reconnect, and never silently drop the request.

Show 5 hidden lines6      this.queue.push(request)7      localStorage.setItem("pendingRides", JSON.stringify(this.queue))8      throw new OfflineError("Ride queued, will submit when online")9    }10    return this.submitRide(request)11  }1213  async processQueue(): Promise<void> {14    const pending = [...this.queue]15    this.queue = []1617    for (const request of pending) {18      try {19        await this.submitRide(request)20      } catch (e) {21        this.queue.push(request)22      }23    }24    localStorage.setItem("pendingRides", JSON.stringify(this.queue))25  }26}2728window.addEventListener("online", () => rideQueue.processQueue())

Infrastructure design

Cloud-agnostic concepts

AWS reference architecture

Multi-region active-active

Uber operates globally with active-active deployments. The mechanics:

1. Kafka cross-region replication uses uReplicator, Uber’s open-source Kafka replicator with zero-data-loss guarantees¹².
2. Cassandra multi-DC writes at LOCAL_QUORUM, reads at LOCAL_ONE for low latency.
3. Redis stays mostly region-local — driver location is intrinsically regional, so cross-region replication of the geo index would just spend bandwidth.
4. DNS-based routing (Route 53 latency-based or equivalent) sends users to the nearest healthy region.
5. Failover is service-by-service: if MSK in one region degrades, uReplicator’s federated mode automatically reroutes producers to the surviving region.

Self-hosted alternatives

Failure modes and operational implications

The architecture above survives most steady-state load. The interesting questions are what happens when it doesn’t.

Practical takeaways

• H3 buys you uniformity, not perfection. Use it for the index and the surge grid; don’t promise exact distances. Watch out for the 12 pentagons per resolution; if your code blindly assumes 6 neighbours it will produce subtle bugs near pentagon centres.
• Batch matching wins in dense cities; greedy wins in sparse ones. Don’t reach for batched assignment in your MVP. The added latency only pays off when there are enough overlapping requests for global optimisation to find a better arrangement than the greedy nearest.
• Hybrid ETA scales further than pure ML. A fast routing engine plus a small residual model is cheaper, more robust, and easier to debug than a single end-to-end neural model. Keep the routing engine.
• Append-only trip storage is worth its quirks. Time-travel queries, reconstructable state, no in-place update contention. Pay the storage cost — it’s small relative to the support and analytics value.
• Surge needs two granularities and three forms of damping. Driver-grid res 9, surge-grid res 7; EMA smoothing, max-delta cap, regulatory ceiling.
• Plan for hot cells, not aggregate load. A single Friday-night event can put more pressure on one Redis shard than the whole rest of the system combined. Pre-shard, throttle, and isolate.

Limitations and follow-ups

• Pooled rides (UberPool / shared rides) require a more complex routing problem with pickup/dropoff ordering constraints; out of scope here.
• Predictive pre-positioning — pushing drivers toward predicted demand before requests arrive — can shave further off wait times. Lyft’s spatial-temporal forecasting work is the canonical reference¹³.
• Pricing as an ML problem rather than a piecewise function — optimise multipliers for market equilibrium, not just supply/demand ratios. Worth a follow-up article.

Appendix

Prerequisites

• Distributed systems fundamentals (CAP theorem, eventual consistency).
• Database concepts (sharding, replication, time-series data).
• Graph algorithms (Dijkstra, bipartite matching basics).
• Basic understanding of ML inference serving.

Terminology

• H3 — Hexagonal Hierarchical Spatial Index, Uber’s open-source geospatial system; 16 resolutions; 12 pentagons per resolution.
• DISCO — Dispatch Optimisation, Uber’s matching service.
• Schemaless / Docstore — Uber’s MySQL-backed sharded datastore family; Schemaless was the original (2014–2016), Docstore is the current evolution.
• CacheFront — the integrated cache layer in Docstore; serves over 150M reads/sec.
• k-ring / gridDisk — set of all H3 cells within k hops of a center cell.
• DeepETA / DeeprETA — Uber’s hybrid ETA model; routing engine plus a small ML residual.
• uReplicator — Uber’s open-source Kafka cross-DC replicator with zero-data-loss guarantees.
• Cadence / Temporal — durable workflow engine (originally built at Uber, later forked as Temporal) used to orchestrate long-running, fault-tolerant business workflows like the trip lifecycle.
• Surge — dynamic pricing multiplier applied when demand exceeds supply in a cell.
• Bipartite matching — assignment problem where two disjoint sets (riders, drivers) are matched to minimise total cost.
• RADAR / RideCheck — Uber’s published fraud-detection (RADAR) and in-trip safety (RideCheck) systems.

References

• H3: Uber’s Hexagonal Hierarchical Spatial Index — Uber blog.
• H3 documentation — spec, resolution tables, primitives.
• H3 GitHub — open-source implementation.
• Uber Marketplace Matching — closest-first → batched matching, in Uber’s own words.
• DeepETA: How Uber Predicts Arrival Times Using Deep Learning.
• DeeprETA: An ETA Post-processing System at Scale — the underlying paper.
• Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL.
• The Architecture of Schemaless, Uber Engineering’s Trip Datastore Using MySQL.
• Evolving Schemaless into a Distributed SQL Database — Docstore.
• How Uber Serves over 150 Million Reads Per Second from Integrated Cache — CacheFront.
• Presto on Apache Kafka at Uber Scale — trillion-message scale.
• Disaster Recovery for Multi-Region Kafka at Uber — uReplicator deployment.
• uReplicator: Uber Engineering’s Robust Kafka Replicator.
• Conducting Better Business with Uber’s Open Source Orchestration Tool, Cadence — workflow engine used for trip lifecycle orchestration.
• Cadence Multi-Tenant Task Processing — sharding and isolation in the same engine.
• Project RADAR: Intelligent Early Fraud Detection System with Humans in the Loop.
• Detecting Abuse at Scale: Locality Sensitive Hashing at Uber Engineering — fraudulent-trip pattern detection.
• RideCheck announcement — Uber — in-trip safety detection from sensor signals.
• Uber Q4 and Full-Year 2024 results — scale anchors.
• Uber Q4 and Full-Year 2025 results.
• Solving Dispatch in a Ridesharing Problem Space — Lyft Engineering — comparable bipartite-matching framing.
• Real-Time Spatial Temporal Forecasting @ Lyft — predictive demand modelling.