Design Uber (Ride Sharing)

#Problem Statement

Design a ride-sharing platform where riders can request rides and drivers can accept them. The system must match riders to nearby available drivers in real time and provide live location tracking.

📖

Real-world: Uber's defining technical problem is geospatial indexing at scale — efficiently answering "which drivers are near this rider?" across millions of constantly-moving GPS points. Their answer became H3, the open-source hexagonal grid system they built and released, which (along with geohashes and quadtrees) is the heart of this design. The security/trust angle is unusually rich here: Uber's 2016 breach — attackers found AWS credentials hardcoded in a private GitHub repo and stole 57M riders'/drivers' data — became infamous because Uber paid the attackers $100K through its bug-bounty program to stay quiet and called it a "bug bounty," leading to a criminal conviction of its security chief for obstruction. It's the canonical cautionary tale for secrets-in-source and breach cover-ups — a perfect thing to reference when the interviewer asks about securing the driver/rider data this system stores.

#Requirements

#Functional

• Rider requests a ride with pickup + destination
• System shows nearby available drivers
• Driver accepts / declines rides
• Real-time location tracking (rider tracks driver en route)
• ETA calculation
• Surge pricing
• Ride history

#Non-Functional

• 15M rides/day globally → ~170 rides/s average
• Driver location update: every 4 seconds per driver → 5M active drivers × 0.25/s = 1.25M location updates/s
• Matching latency: < 3 seconds from request to match
• Global: multiple regions, each city is semi-independent
• High availability: can't afford downtime during peak hours

#Core Design

#The Two Core Challenges

#Geo-Index: Geohash

Geohashencodes a lat/lng into a base-32 string. Adjacent strings share a common prefix. Resolution scales with string length.

lat=37.7749, lng=-122.4194 (San Francisco)
  Geohash length 6: "9q8yy2"  → ~1.2 km² cell
  Geohash length 5: "9q8yy"   → ~4.8 km² cell

To find nearby drivers:
  1. Hash rider's location → geohash prefix
  2. Include 8 neighboring cells (handles cell boundary problem)
  3. Query Redis: GEOSEARCH or SET of driver IDs per geohash cell

AlternativeQuadtree — recursive spatial partition. More efficient for uneven density (more cells in NYC than Montana). More complex to implement.

Production choiceUber uses S2 library (Google's spherical geometry library) which uses space-filling Hilbert curves. Redis GEO commands (GEOADD, GEORADIUS) use geohash internally.

#Driver Location Store

Driver locations update every 4s. Need to:

• Accept 1.25M writes/s
• Query: "all drivers within 5km of (lat, lng)"

Redis (in-memory, per-region cluster):
  Key: "drivers:{geohash_prefix_5}"
  Value: sorted set of { driver_id: encoded_lat_lng }
  TTL: 30s (remove offline drivers automatically)

On each driver update:
  ZREM old_geohash_key driver_id
  ZADD new_geohash_key score(lat_lng) driver_id
  EXPIRE both keys 30s

Alternatively, use Redis GEOADD + GEORADIUS which handles this natively.

#Architecture

Driver App → Location Service → Redis (geo-index, per region)
                                      ↑
Rider App → Matching Service → query nearby drivers from Redis
                 ↓
          Dispatch Service → assign driver
                 ↓
          Trip Service (Postgres) → create trip record
                 ↓
          Notification Service → push to driver + rider
                 ↓
          Tracking Service (WebSocket) → live location during trip

#Matching Algorithm

1. Rider submits pickup location
2. Matching Service → query Redis for drivers in geohash cells around pickup
3. Filter: available=true, rating >= threshold, vehicle_type matches
4. Rank by: (distance * weight) + (acceptance_rate * weight) + (driver_score * weight)
5. Top N candidates → send ride request notification (parallel)
6. First to accept → assigned; others → cancelled
7. If no accept in 10s → expand search radius

#Surge Pricing

surge_multiplier = f(demand / supply)
  demand = active ride requests in area in last 5 min
  supply = available drivers in area

Zones: geohash cells aggregated into pricing zones
If demand/supply > threshold → increase multiplier
Display to rider before confirmation

#Key Design Decisions

#ETA Calculation

Simple approach: distance / average_speed_for_area_and_time_of_day (historical data).

Production: integrate with mapping API (Google Maps, HERE) for real road network routing with real-time traffic.

#Security Considerations

#Interview Tips