Design Real-Time GPS Tracking

Functional Requirements

• ·Ingest location updates: Receive GPS coordinates from millions of drivers every 4 seconds
• ·Real-time delivery: Push driver location to riders tracking their trip
• ·Location history: Store GPS traces for trip reconstruction, analytics, fraud detection
• ·Geospatial queries: Find nearby drivers (for matching), compute distances
• ·Map rendering: Display driver movement on client maps with smooth animation

Non-Functional Requirements

• ·Throughput: Handle 1.25M location updates/second (5M drivers × 1/4s)
• ·Latency: Location visible to rider within 1-2 seconds of driver's GPS reading
• ·Storage: Retain location history for 90 days (compliance, analytics)
• ·Availability: 99.9% for ingestion, 99.99% for delivery to riders

Data Flow: Driver Location Update to Rider’s Screen

1. Driver app reads GPS → batches 1-2 readings → sends HTTP POST

2. Location Ingestion Service validates, enriches (add city_id), publishes to Kafka

3. Redis consumer: Updates GEOADD available_drivers:{city} driver_id lng lat (for matching)

4. Cassandra consumer: Writes to location_history table (for analytics/compliance)

5. Trip Tracker consumer: If driver is on an active trip:

• ·Look up rider's WebSocket connection in Redis
• ·Push location update to rider's WebSocket Gateway
• ·Gateway delivers to rider's app

1. Rider app: Receives update → animates driver marker smoothly between previous and new position (client-side interpolation between 4-second updates)

Deep Dive 1: Client-Side Smooth Animation

Problem: GPS updates arrive every 4 seconds. Without interpolation, the driver marker “teleports” every 4 seconds.

Solution: Client-side animation interpolation.

This creates the illusion of smooth, continuous movement even with 4-second update intervals.

Deep Dive 2: Ingestion Optimization

Batching on client: Driver app collects 2-3 GPS readings, sends as single request. Reduces connection overhead by 60%.

Deduplication: If driver hasn’t moved > 5 meters since last update, don’t send (parked/idle). Reduces traffic by ~30% during idle periods.

Protocol choice:

Uber’s choice: HTTP with batching for reliability. Accept slightly higher overhead because location data is critical for matching and tracking.

Deep Dive 3: Geospatial Storage and Queries

Redis GEO for current locations:

• ·Under the hood: sorted set with geohash as score
• ·O(N+log(M)) for radius query where N = returned results, M = total entries
• ·Memory: 5M drivers × ~100 bytes = ~500 MB (fits in single Redis)

Cassandra for location history:

• ·Write-optimized (LSM tree)
• ·Time-series access pattern (query driver's route for a specific trip/date)
• ·TTL: 90 days (auto-cleanup)

Bottlenecks

1. Kafka throughput: 1.25M events/sec requires significant Kafka cluster

• ·Mitigation: 500+ partitions, partition by city_id for locality

1. Redis GEO hot cities: NYC/SF may have 500K drivers → hot partition

• ·Mitigation: Split large cities into zones, each with own Redis key

1. WebSocket connections: 2M concurrent trips × 2 users = 4M WebSocket connections

• ·Mitigation: Horizontal WebSocket gateway fleet, sticky sessions

Key Tradeoffs

Monitoring

• ·Location update lag: Time from GPS reading to Redis update — alert if > 5s
• ·Kafka consumer lag: Alert if processing falls behind > 10s
• ·Redis GEO query latency: Alert if > 10ms
• ·WebSocket delivery rate: Alert if < 95% of updates delivered
• ·GPS accuracy distribution: Track % of low-accuracy readings