Ride Sharing

Problem Statement & Requirements

Design a ride-sharing platform that matches riders with nearby drivers in real-time, handles the full trip lifecycle from request to payment, and provides live location tracking — similar to Uber, Lyft, Grab, or DiDi.

Functional Requirements

• Request a ride — rider enters pickup and dropoff locations; system shows ETA and fare estimate
• Match rider to driver — find the optimal nearby driver based on proximity, ETA, and driver rating
• Real-time location tracking — both rider and driver see each other's live position on a map during the trip
• Trip lifecycle — request → match → driver en route → pickup → in-trip → dropoff → payment → rating
• Fare calculation — based on distance, time, base fare, surge multiplier, tolls
• Surge pricing — dynamic pricing based on supply/demand ratio in a geographic area
• Driver availability management — drivers go online/offline; system tracks who is available and where
• Ride types — UberX, UberXL, Black, Pool (shared rides), etc.
• Payment — charge rider, pay driver; support cards, wallets, cash
• Ratings — mutual ratings (rider rates driver, driver rates rider)
• Trip history — riders and drivers can view past trips
• ETA estimation — estimated time of arrival for both pickup and dropoff

Non-Functional Requirements

• Low latency matching — rider matched to driver within < 5 seconds
• Real-time location updates — position updates every 3-4 seconds from all active drivers
• High availability — 99.99% for ride requests (core revenue path)
• Scalability — 500K concurrent drivers, 1M+ concurrent rides
• Consistency — a driver must NEVER be matched to two riders simultaneously
• Geographic coverage — operate in 10,000+ cities across 70+ countries
• Surge responsiveness — pricing adjusts within 1-2 minutes of supply/demand shift

Out of Scope

• Uber Eats / delivery platform
• Autonomous vehicle integration
• Driver onboarding / background checks
• Detailed mapping / routing engine internals (use Google Maps / OSRM)

Scale Estimations

Traffic

Storage

Bandwidth

Hardware Estimate

This first layer defines the system boundary. The next chapters add application logic and data dependencies. After examining the request paths and tradeoffs, we will add operational safeguards and bring the complete architecture together.

API Design

Request a Ride

POST /api/v1/rides/request
Authorization: Bearer <rider_token>

Request:
{
  "pickup": {"lat": 40.7484, "lng": -73.9857},       // Empire State Building
  "dropoff": {"lat": 40.7580, "lng": -73.9855},      // Times Square
  "ride_type": "uberx",
  "payment_method_id": "pm_card_4242",
  "passenger_count": 2
}

Response (200 OK):
{
  "ride_id": "ride-abc123",
  "status": "matching",
  "fare_estimate": {
    "min": 1200,               // cents
    "max": 1600,
    "currency": "usd",
    "surge_multiplier": 1.0,
    "breakdown": {
      "base_fare": 250,
      "distance_charge": 680,  // $0.85/mile × 0.8 miles
      "time_charge": 270,      // $0.25/min × ~10.8 min
      "booking_fee": 200
    }
  },
  "pickup_eta_seconds": 180,    // driver arrives in ~3 min
  "dropoff_eta_seconds": 780    // total trip ~13 min
}

// Client opens WebSocket for real-time updates:
// ws://api.example.com/ws/rides/ride-abc123

Driver Location Update (High-Frequency)

// Sent via WebSocket or gRPC stream (not REST — too much overhead)

Message (every 3-4 seconds from driver app):
{
  "driver_id": "drv-xyz789",
  "lat": 40.7500,
  "lng": -73.9860,
  "heading": 45,                // degrees (0=north)
  "speed_mph": 22,
  "timestamp": 1712150400123,   // ms precision
  "trip_id": "ride-abc123",     // null if not on active trip
  "availability": "available"   // available | on_trip | offline
}

Driver Accepts/Declines Ride Offer

POST /api/v1/rides/{ride_id}/respond
Authorization: Bearer <driver_token>

Request:
{
  "action": "accept"            // accept | decline
}

Response (200 OK):
{
  "ride_id": "ride-abc123",
  "status": "driver_en_route",
  "rider": {
    "name": "Alice",
    "rating": 4.9,
    "pickup": {"lat": 40.7484, "lng": -73.9857, "address": "350 5th Ave"}
  },
  "navigation_url": "https://maps.example.com/route?to=40.7484,-73.9857"
}

Trip Status Updates (WebSocket Push)

// WebSocket messages pushed to both rider and driver apps:

// Driver matched:
{"type": "driver_matched", "driver": {"name": "Bob", "rating": 4.85,
 "vehicle": {"make": "Toyota", "model": "Camry", "plate": "ABC 1234"},
 "eta_seconds": 180, "location": {"lat": 40.7520, "lng": -73.9870}}}

// Driver location update (every 3-4s while en route):
{"type": "driver_location", "lat": 40.7505, "lng": -73.9862,
 "eta_seconds": 120, "heading": 195}

// Driver arrived at pickup:
{"type": "driver_arrived", "message": "Your driver has arrived"}

// Trip started:
{"type": "trip_started", "at": "2026-04-03T10:05:00Z"}

// Trip completed:
{"type": "trip_completed",
 "fare": {"total": 1435, "currency": "usd", "breakdown": {...}},
 "dropoff_at": "2026-04-03T10:18:30Z",
 "prompt_rating": true}

Data Model

Trip Record

Driver State

Trip State Machine

Core Design Decisions

Decision 1: Geospatial Indexing — How to Find Nearby Drivers Fast

This is the most performance-critical operation. Every ride request needs nearby drivers in < 100 ms.

Option A: PostGIS (PostgreSQL + Spatial Index)

Option B: Redis GEO Commands

Option C: H3 Hexagonal Grid + Redis (Uber's Approach)

Recommendation: H3 Grid + Redis

Use H3 for cell-based operations (surge pricing, supply/demand per area).
Use Redis GEO for precise nearest-driver queries within cells.
Both updated from the same location stream (Kafka consumer).

Decision 2: Matching Algorithm — Driver Selection

Decision 3: Preventing Double-Dispatch

Detailed Flow Diagrams

Ride Request → Match → Trip Flow

Location Ingestion Pipeline

Fare Calculation Flow

Location updates are frequent and quickly become stale. Coalesce updates and keep only the freshest useful position in the nearby-driver serving path, while retaining trip-critical events durably. Match from a bounded candidate set and measure estimated arrival time; geometric distance alone can choose a driver on the wrong side of a river.

Surge Pricing

ETA Estimation

Shared Rides (UberPool / Lyft Shared)

Handling Edge Cases

Driver Goes Offline Mid-Trip

Problem: Driver's app crashes or phone dies during active trip

Detection:
  No location update for > 60 seconds (normally every 3-4s)

Response:
  1. Flag trip as "driver_unreachable"
  2. Attempt push notification / SMS to driver
  3. After 5 minutes no response:
     → Contact rider: "We've lost contact with your driver"
     → Offer: cancel with full refund, or wait
  4. Calculate fare based on last known position
     → Charge for distance/time up to disconnect point
  5. Rider gets free cancellation + credit for inconvenience

Rider No-Show

Driver arrives at pickup → starts 5-minute wait timer

  T+0:   Driver arrives, rider notified
  T+2m:  Reminder notification to rider
  T+5m:  Timer expires
         → Trip auto-cancelled as "rider_no_show"
         → Rider charged cancellation fee ($5-10)
         → Driver compensated for wait time
         → Driver returns to available pool

Route Manipulation (Fraud)

Problem: Driver takes a longer route to inflate fare

Detection:
  1. Compare actual route distance with optimal route distance
     ratio = actual_distance / optimal_distance
     If ratio > 1.3 (30% longer):
       → Flag for review

  2. Real-time monitoring: if driver deviates significantly
     from navigation route → alert rider in app

Response:
  → Charge rider the ESTIMATED fare (based on optimal route)
  → Deduct excess from driver's payout
  → Repeated offenses → driver deactivation

Concurrent Ride Requests in Same Area

Problem: 100 riders request UberX in Times Square simultaneously
         Only 30 drivers available

Solution: Batch matching (2-second windows)

  T+0.0s: Ride requests R1-R100 arrive
  T+2.0s: Matching engine collects batch

  Assignment problem (bipartite matching):
  Riders: [R1, R2, ..., R100]
  Drivers: [D1, D2, ..., D30]

  Objective: Minimize total pickup ETA across all matches
  Algorithm: Hungarian algorithm or greedy with re-optimization

  Result:
  → 30 riders matched to optimal drivers
  → 70 riders: "Looking for drivers" (retry in 10s)
  → Surge pricing kicks in (demand >> supply) → attracts more drivers

Payment Failure After Trip

Problem: Trip completes but rider's card declines

  1. Attempt charge → card declined
  2. Retry with backup payment method (if on file)
  3. If no backup: rider's account flagged
     → Must add valid payment before next ride
  4. Driver paid regardless (platform absorbs the loss temporarily)
  5. Rider charged on next successful payment method addition
  6. Repeated payment failures → account suspension

Tradeoffs & Design Decisions Summary

Reliability & Fault Tolerance

Single Points of Failure & Mitigations

Graceful Degradation

Tier 1 (ETA service down):
  → Use cached ETA matrix between H3 cells
  → Fallback: straight-line distance × 1.4 / avg_speed
  → Less accurate but ride request still works

Tier 2 (Surge pricing down):
  → Default to 1.0× (no surge) for all areas
  → Rides work, just no dynamic pricing
  → Driver incentive temporarily lost

Tier 3 (Kafka location pipeline down):
  → Drivers write location directly to Redis (bypass Kafka)
  → Lose analytics/breadcrumbs temporarily
  → Matching continues with live positions

Tier 4 (Redis geo index down):
  → Fall back to PostGIS queries (slower, ~50 ms)
  → Matching still works, just higher latency
  → Reduce candidate pool size to compensate

Tier 5 (Trip DB shard down):
  → Active trips on that shard: tracked in memory/Redis
  → New rides on other shards continue normally
  → Failover to standby (< 30s)
  → In-flight trips recovered from Redis state

High-Level Architecture

Component Breakdown

Full System Architecture (Production-Grade)

Offer one ride to several drivers under a timed acceptance policy. Two accept almost together. Identify the single conditional state change that chooses the winner, and specify what the others see. Repeat the exercise with a rider cancellation racing the winning acceptance.

Interview Tips

1. Lead with the location ingestion challenge — "500K drivers sending GPS every 3-4 seconds = 125K writes/sec. You can't poll a SQL database for this." Explain: WebSocket → Kafka → multiple consumers (geo index, trip tracking, analytics). This shows you understand the scale of the real-time data pipeline.

2. H3 hexagonal grid is the key insight — Don't just say "geohash." Explain why Uber open-sourced H3: uniform cell area (unlike geohash rectangles distorted at poles), clean neighbor traversal (6 neighbors, all equal), and dual use for both proximity queries and surge pricing aggregation per cell.

3. Matching is a scoring problem, not just nearest driver — ETA matters more than straight-line distance. A driver 500m away facing away is worse than one 800m away heading toward you. Scoring: pickup_ETA × 0.5 + driver_rating × 0.15 + acceptance_rate × 0.1 + idle_time × 0.15 + heading × 0.1.

4. Double-dispatch prevention = Redis SET NX EX — Same atomic lock pattern as ticket booking. Driver state transitions (available → offered → on_trip) must be atomic. SET NX EX gives you: atomicity, TTL-based timeout, no distributed lock complexity.

5. Batch matching for high demand — Most candidates describe greedy one-at-a-time matching. Explain: during peak, collect requests in 2-second windows, solve bipartite assignment to minimize total pickup ETAs. Hungarian algorithm or greedy with re-optimization. Shows algorithmic depth.

6. Surge pricing is a supply/demand feedback loop — Compute ratio per H3 cell every 1-2 minutes. Demand = ride requests, supply = available drivers. Surge incentivizes drivers to move to high-demand areas, and reduces rider demand (some wait). Equilibrium is the goal, not maximum revenue.

7. ETA is harder than it looks — Routing engine gives baseline, but ML model captures: time-of-day patterns, weather, events, historical accuracy. Pre-compute ETA matrix between popular H3 cells to reduce real-time routing calls by 70%.

8. Shared rides (Pool) show algorithmic depth — Detour ratio constraint: matched riders must add < 40% extra distance. Ordering optimization (who gets picked up/dropped off first). Real-time re-matching (add co-rider after trip starts).

9. Graceful degradation is critical — If Redis geo index is down, fall back to PostGIS (slower but works). If Kafka is down, bypass to Redis directly. If surge engine is down, default to 1.0×. Every component has a degraded mode.

10. End with the scale numbers — "125K location updates/sec ingested via Kafka. Matching in < 5 seconds using Redis GEO + H3 across 500K drivers. 1M concurrent trips tracked via WebSocket push every 3-4 seconds. Surge recalculated every 1-2 minutes across 100K+ H3 cells."