Ride-Sharing Analytics Platform
Design a real time analytics platform for a ride sharing company like Uber or Lyft. The system must ingest GPS location streams from 5 million active drivers (reporting every 2 seconds), power dynamic surge pricing ba...
Design a real-time analytics platform for a ride-sharing company like Uber or Lyft. The system must ingest GPS location streams from 5 million active drivers (reporting every 2 seconds), power dynamic surge pricing based on supply-demand ratios per geographic zone, compute accurate ETAs, and produce daily KPI dashboards, trip volume, revenue, driver utilization, rider wait times, and city-level performance. The platform spans 500+ cities worldwide. How would you design the data infrastructure end to end?
How to Approach This Problem
How to Approach This Problem Ride sharing system design looks like a standard streaming pipeline question until the interviewer starts probing. The three problems that separate strong answers from average ones are each fundamentally different in nature: geospatial indexing, stream computed caching, and distributed state machine consistency. Surface level answers treat all three as database or Kafka problems. Strong answers identify the right tool class for each. The Three Hard Problems Unique to Ride Sharing Real time geospatial driver matching is a geospatial index problem, not a database query problem. All 5 million active drivers update their location every 3 5 seconds. When a rider reque
Clarifying Questions to Ask the Interviewer
Functional Requirements How many active drivers are streaming GPS at any given time? (1M? 5M? 10M?) What is the GPS reporting frequency? (every 1 second? 2 seconds? 5 seconds?) What geospatial indexing system do we use for surge pricing zones? (H3 hexagons? S2 cells? Geohash?) How frequently should surge pricing be recalculated? (every 10 seconds? 30 seconds? 1 minute?) What trip lifecycle events do we need to capture? (request, match, driver en route, pickup, in trip, dropoff, payment, rating?) What KPIs are required for the analytics dashboard? (trip volume, revenue, driver utilization, wait times, surge frequency, cancellation rates?) Do we need real time ETA computation? What accuracy SL
Envelope Estimation & Capacity Planning
Throughput Math Metric Value Calculation Active drivers (peak) 5,000,000 Given requirement GPS report interval 2 seconds Given Location updates per second 2,500,000 5M / 2 sec Location event size ~200 bytes driver id, lat, lng, heading, speed, timestamp, trip id Raw GPS ingestion rate ~500 MB/sec 2.5M 200 bytes Raw GPS per day ~43 TB/day 500 MB/sec 86,400 sec After Parquet compression ~4.3 TB/day ~10:1 compression ratio Trips per day 20,000,000 Given (~230 trips/sec avg) Trip events per day ~160,000,000 20M trips ~8 lifecycle events each Trip event ingestion rate ~1,850/sec 160M / 86,400 sec Ride requests per second (peak) ~5,000 10x average during rush hour Surge Pricing Computation Paramet
Architecture Walkthrough
End to End Data Flow "Let me walk through the five main data paths: GPS ingestion, ride matching, surge pricing, trip lifecycle, and batch analytics." 1. GPS Telemetry Ingestion (Hot Path) The driver app sends a location heartbeat every 3 seconds. Each event is a compact payload: Flow: Driver App API Gateway (rate limiting + auth) Kafka driver.location topic Flink Geo Indexing job Redis Flink performs three operations on each GPS event: Step Operation Output 1 Convert (lat, lon) to H3 hex index at resolution 9 h3 index: 89283082837ffff 2 Update driver location in Redis HSET driver:loc:{driver id} h3 {h3 index} lat {lat} lon {lon} ts {ts} 3 Set TTL on driver key (30 seconds) If driver goes si
Component Deep Dive
H3 Hexagonal Indexing "H3 is Uber's open source hierarchical spatial index. It partitions the globe into hexagonal cells at 16 resolution levels. We use it because hexagons have uniform neighbors and consistent area, unlike squares or geohashes." Why hexagons over squares (geohash)? Property Geohash (Squares) H3 (Hexagons) Neighbor distance Varies (diagonal vs edge) Uniform, all 6 neighbors equidistant Edge artifacts Boundary discontinuities at edges Smooth transitions between cells Area consistency Varies by latitude (up to 2x) Near constant area per resolution Hierarchical Yes (prefix based) Yes (parent/child functions) K ring search Irregular shape Clean concentric rings Resolution levels
Data Modeling
Core Tables GPS Telemetry (High Volume Time Series) Storage note: Raw GPS telemetry is too large for Postgres long term (~43 TB/day uncompressed). The operational database holds the last 24 hours for real time queries. Historical data lives in the data lake as Parquet files partitioned by date/city id/h3 index r7 . Ride Requests Trips Surge Snapshots (Time Series for Analysis) Driver Availability (Operational State) Indexing Strategy Summary Table Partition Key Hot Indexes Rationale gps telemetry timestamp (daily) (driver id, ts), (h3 r9, ts) Time range + spatial queries ride requests , (pickup h3 r9, status), (city, time) Match lookup, city dashboards trips , (city, time), (pickup h3 r7, ti