Design Uber / Ride Sharing

Design a ride-sharing platform like Uber. Riders request rides, drivers accept, and the system matches them in real time. Track driver location, display ETA, and handle surge pricing.

Capacity Estimation

• Active drivers: 5M worldwide, 1M online at peak
• Location updates: 1M drivers × 1 update/5s = 200K location writes/sec
• Ride requests: 1M concurrent rides → ~200K new requests/hour
• Geospatial index size: 1M driver locations × 64 bytes = ~64 MB — fits in Redis

Architecture

[Driver App]
  → location update every 5s
  → [Location Service]
        → Redis Geo (GeoHash index)
        → Kafka (location events for analytics)

[Rider App]
  → ride request
  → [Matching Service]
        → queries Redis Geo for nearby drivers
        → sends offer to selected driver
        → [Driver App] accepts

[Trip Service]
  → manages active trip state
  → streams location to rider via WebSocket

[Pricing Service]
  → calculates surge multiplier from supply/demand ratio
  → feeds pricing to Matching Service

API Design

// Driver
PUT /drivers/{driverId}/location
Body: { lat, lng, heading, speed }

PATCH /drivers/{driverId}/status  { status: AVAILABLE | ON_TRIP | OFFLINE }

// Rider
POST /rides/request
Body: { riderId, pickup: {lat,lng}, destination: {lat,lng} }
Response: { rideId, driverEta, estimatedFare }

GET /rides/{rideId}/driver-location  → real-time via WebSocket

// Matching
GET /drivers/nearby?lat=X&lng=Y&radius=2km&limit=10

Database Design

Driver locations (Redis GEO — O(log N) geospatial queries)

GEOADD drivers:available <lng> <lat> "driver:42"
GEOSEARCH drivers:available FROMMEMBER <point> BYRADIUS 2 km ASC COUNT 10

Trips (PostgreSQL — ACID, payment reconciliation)

rides
  id          UUID    PK
  rider_id    UUID
  driver_id   UUID
  pickup      POINT   (PostGIS geometry)
  destination POINT
  status      ENUM    (REQUESTED, ACCEPTED, ONGOING, COMPLETED, CANCELLED)
  started_at  TIMESTAMP
  ended_at    TIMESTAMP
  fare        DECIMAL

Trip tracking (Cassandra — time-series location history)

trip_location
  trip_id     UUID    PK
  recorded_at TIMEUUID
  lat, lng    DOUBLE

Scaling

Geospatial matching at scale

Redis GEO uses GeoHash under the hood — O(log N) radius search. With 1M active drivers:

• GEOSEARCH radius 2km returns results in <1ms
• Partition drivers by city (each city has its own Redis key)

Driver matching algorithm

1. Query Redis GEO for nearest 10 available drivers
2. Filter by vehicle type, rating
3. Offer ride to nearest driver (5-second acceptance window)
4. If rejected, offer to next driver

Surge pricing

surge_multiplier = demand / supply
where demand = ride_requests_last_10min in zone
      supply = available_drivers_last_10min in zone

if surge > 1.5: show surge warning to rider

• Redis GEO vs PostGIS: Redis GEO is faster (in-memory, O(log N)); PostGIS supports complex polygon queries and is durable. Use Redis for real-time matching, PostGIS for analytics.
• Push vs poll for driver location: Drivers push every 5s regardless. Riders poll every 3s for ongoing trips (or WebSocket for real-time map updates).
• Matching algorithm: greedy nearest-driver is fast but sub-optimal. ML-based matching (considering traffic, driver idle time) improves ETA accuracy but adds latency.

• Location write storm: 200K writes/sec to Redis. Use pipeline batching and Redis Cluster.
• Matching hotspots: airport, stadium events create thousands of simultaneous requests. Queue requests; serve in order.
• ETA accuracy: poor ETA erodes trust. Integrate with Google Maps / Here Maps API for real-time traffic.

• Redis GEO down: fall back to PostgreSQL PostGIS. Matching degrades from <1ms to ~10ms — still acceptable.
• Matching Service down: riders see 'no drivers available'. Trip requests queue; retry when service recovers.
• Driver app crash: trip status maintained server-side. Driver reconnects and resumes trip.