Ride-Sharing System Design Interview Guide

Trip state (driver assignment, trip status) requires strong consistency because two riders matching the same driver is a hard business error — one trip must be rejected. Location data, by contrast, is continuously refreshed. A stale GPS position by 2 seconds is acceptable because the next heartbeat will correct it. This split allows you to use a strongly consistent RDBMS for trip records while using a high-throughput, eventually consistent spatial index (Redis) for location.

GPS heartbeat frequency is a battery-vs-accuracy trade-off on the driver's phone. 1 Hz (every second) drains battery significantly and produces location data faster than the spatial index can usefully act on. 10-second intervals make ETA predictions visibly laggy when a driver is approaching. 4 seconds is a common production compromise: fast enough for sub-10-second ETA refresh on the rider app, slow enough to not drain the driver's battery on an 8-hour shift.

Postgres can do geospatial queries via PostGIS, but 125K upserts/second will saturate its write path and create index bloat as every driver update re-indexes a B-tree entry. Redis GEOADD is a sorted-set operation that completes in microseconds and handles the write rate comfortably. The trade-off is durability: if the Redis primary dies, you lose the last few seconds of position data. This is acceptable — drivers will re-send their GPS within 4 seconds, and the index rebuilds automatically.

Mobile push (FCM/APNs) has two problems for dispatch: latency and reliability. FCM delivery can take 1–30 seconds depending on battery optimization mode, and the platform provides no acknowledgement that the message was received by the app in time. For a 10-second accept window, a 5-second FCM delay is unacceptable. WebSocket connections from the driver app provide sub-100ms delivery and a clear acknowledgement path. The tradeoff is connection overhead: 1M persistent WebSocket connections requires a well-designed connection server (typically a stateful layer separate from the stateless matching logic).

The trip assignment is a distributed locking problem: two concurrent rider requests must not claim the same driver. Postgres row-level locking with SELECT ... FOR UPDATE provides this guarantee natively. The trip write QPS is low (rides/second, not hundreds of thousands), so Postgres is not a throughput bottleneck. A NoSQL database would require building a distributed lock on top — adding complexity without benefit.

Geohash encodes coordinates into a base-32 string. Longer strings = smaller cells. Cells with the same prefix are geographically adjacent. This makes lookups trivially simple in a Redis sorted set — encode both the driver and rider position to the same precision and compare scores. The weakness is at cell boundaries: a rider at the edge of cell A and a driver 50 meters away in cell B won't have a common prefix, so you must also query the 8 neighboring cells. Redis GEOSEARCH handles this automatically via its internal geohash scoring.

A quadtree recursively subdivides space into four quadrants until each cell contains at most N drivers (e.g. N=10). This means dense cities (Manhattan) get fine-grained cells while rural areas get coarse cells — matching their actual driver density. Uber uses a hexagonal grid (H3) which achieves similar adaptive behavior with better geometric properties (no edge effects at poles). Quadtrees are more complex to implement in Redis; for interview purposes, geohash is the correct first answer.

// Request
POST /rides/request
Content-Type: application/json
Idempotency-Key: <client-generated UUID>          // ← dedup on double-tap

{
  "pickup":        { "lat": 37.7749, "lng": -122.4194 },
  "dropoff":       { "lat": 37.7863, "lng": -122.4102 },
  "vehicle_type":  "standard",          // standard | xl | black
  "idempotency_key": "550e8400-e29b-41d4-a716-446655440000"
}

// 200 OK — trip created or existing trip returned on duplicate key
{
  "ride_id":              "trip_abc123",
  "status":               "REQUESTED",
  "eta_pickup_seconds":   240,
  "fare_estimate_cents":  1450,
  "surge_multiplier":     1.2,
  "created_at":           "2026-04-19T22:00:00Z"
}

// 429 Too Many Requests — rider rate-limited (> 5 active requests/hour)
// 409 Conflict — returned if an active trip already exists for this rider

// WebSocket frame (same connection used for offer receipt)
// Sent every 4 seconds from the driver app
{
  "type":      "location_update",
  "driver_id": "drv_xyz789",
  "lat":       37.7812,
  "lng":       -122.4130,
  "heading":   270,             // degrees, 0=north
  "speed_kmh": 32,
  "timestamp": "2026-04-19T22:00:04Z"
}

// Server ACK (sent back on same WS connection)
{
  "type":   "location_ack",
  "status": "ok"
}

// If driver has been matched to a pending trip, ACK includes the offer:
{
  "type":        "ride_offer",
  "ride_id":     "trip_abc123",
  "pickup":      { "lat": 37.7749, "lng": -122.4194, "address": "Market St & 4th" },
  "dropoff":     { "lat": 37.7863, "lng": -122.4102, "address": "Union Square" },
  "rider_name":  "Alex R.",
  "rider_rating": 4.8,
  "fare_estimate_cents": 1450,
  "expires_at":  "2026-04-19T22:00:14Z"   // 10-second accept window
}

The road network graph for a city is a large, read-only data structure (typically 200 MB–2 GB as a compressed adjacency graph with travel time weights). Loading it into Redis would create an enormous serialization overhead — every ETA request would require deserializing a graph that is orders of magnitude larger than the query result. Instead, ETA service pods load the graph on startup into process memory. Live traffic data (speed adjustments per road segment) is a much smaller overlay and can be cached in Redis or fetched via an HTTP cache from a traffic API.

Every 30–60 seconds, the Pricing Service scans all active geohash-6 cells in the system. For each cell, it computes the supply/demand ratio: count of available drivers vs. open ride requests in the past 5-minute window. When demand exceeds supply by a threshold (e.g. demand/supply > 1.5), the surge multiplier activates. The multiplier is capped (typically 5×–8× in production) and is applied to the base fare at trip creation time, not at payment time. The computed multiplier is written to surge:cell:{geohash6} in Redis with a 120-second TTL.

Instead of acquiring a row lock on the driver record during matching (which serializes all concurrent matches), use an optimistic update: UPDATE trips SET driver_id=D9 WHERE trip_id=T1 AND driver_id IS NULL. If two concurrent requests both try to assign D9, only one will succeed (the other will update 0 rows and retry with the next candidate). This keeps the matching loop lock-free in the common case and only serializes on the rare double-claim.

Rather than matching each ride request independently, accumulate requests for 1–2 seconds and match them as a batch against the available driver pool. This allows the system to globally optimize assignments (minimize total wait time across all pending requests) rather than greedily assigning the nearest driver to each request in arrival order. Uber's dispatch engine does this for UberPool and surge scenarios. The trade-off is a 1–2 second latency penalty for the first request in each batch window.