Design a Real-Time Driver Tracking System for a Food Delivery App

High-level design Build an event-driven real-time tracking platform with three main paths: driver ingest, real-time fanout, and query/storage. Drivers continuously publish GPS updates. The backend validates and enriches them, updates the driver’s latest position, maps the driver to any active delivery order, and pushes updates only to the customer tracking that order. 1. Driver mobile to backend Each driver app runs a lightweight location publisher: - Collect GPS coordinates every few seconds, for example every 2 to 5 seconds while on an active delivery, less frequently when idle. - Include driver_id, current order_id if assigned, latitude, longitude, speed, heading, timestamp, app version, battery/network hints, and a sequence number. - Apply client-side throttling and movement-based filtering so the app avoids sending unchanged positions. - Batch or coalesce updates during poor connectivity, then send the latest one first when reconnected. Recommended protocol from driver to backend: - HTTPS for periodic location upload is the simplest and most robust choice. - Use a small POST request to a Location Ingest API. - For very high efficiency, gRPC streaming is also a strong option if mobile support and operational maturity are available. Practical choice: - Start with HTTPS because it works well through mobile networks, proxies, and existing API gateways. - Optimize with compression, compact payloads, adaptive send frequency, and regional edge endpoints. Ingest flow: - Driver App - API Gateway or Load Balancer - Authentication and rate limiting - Location Ingest Service - Message broker for async processing 2. Backend services Core services - API Gateway: terminates TLS, authenticates drivers and customers, applies rate limits. - Location Ingest Service: validates payloads, drops stale or duplicate updates, timestamps events, publishes to a broker. - Message Broker: Kafka, Pulsar, or Kinesis for durable high-throughput event streaming. - Driver State Service: consumes location events and maintains latest known driver state in a fast store such as Redis or DynamoDB. - Order Tracking Service: maps driver_id to active order_id and customer subscription channels. - Realtime Fanout Service: pushes location updates to the correct customer connection. - Order Service: source of truth for order lifecycle, assignment, status changes, restaurant pickup, delivery completion. - ETA Service: optionally recalculates ETA using latest traffic-aware route and driver movement. - Historical Storage Service: stores location history for debugging, analytics, dispute resolution, and ML. - Monitoring and Alerting: tracks latency, dropped messages, stale driver positions, and regional outages. Processing pipeline - Driver sends location update. - Ingest service validates auth, schema, timestamp freshness, and plausibility. - Event is written to broker. - Driver State consumer updates latest location cache keyed by driver_id. - Order Tracking consumer checks whether the driver is currently assigned to an active order. - If yes, it publishes a customer-scoped tracking event. - Realtime Fanout sends the update to the subscribed customer app. - Historical consumer stores events in long-term storage. 3. Customer mobile receiving real-time updates Recommended pattern: - Customer app opens a WebSocket connection after entering the order tracking screen. - The app authenticates and subscribes to a single order tracking channel, such as order_id. - Backend verifies the customer is authorized to view that order. - Fanout service sends only updates for that order. - On initial connect, the app receives a snapshot: latest driver location, order status, ETA, last update time. - Then it receives incremental updates in near real time. Fallbacks: - If WebSockets are blocked or unstable, use Server-Sent Events or short polling as fallback. - For backgrounded apps, use push notifications only for major milestones, not continuous tracking. 4. Protocol choices and justification Driver to backend: HTTPS POST - Strong compatibility on mobile networks. - Easier retries, auth, observability, and gateway integration. - Good enough for 50,000 active drivers if updates are throttled sensibly. - Less operational complexity than MQTT. Customer to backend: WebSockets - Best fit for server-to-client real-time updates. - Avoids wasteful polling from 200,000 customers. - Low latency and efficient for many small push messages. - A customer typically tracks one order, so subscription logic is simple. Broker internal communication: Kafka or similar - Decouples ingest from fanout and storage. - Handles spikes, replay, and multiple downstream consumers. - Supports partitioning for horizontal scale. Why not polling for customers: - With 200,000 active customers, frequent polling creates large unnecessary QPS even when location has not changed. - Higher latency and poorer battery/network efficiency. Why not MQTT end-to-end: - Technically suitable for mobile telemetry, but adds client and broker complexity and may be unnecessary unless the organization already operates MQTT at scale. - For this use case, HTTPS plus WebSockets is simpler and usually sufficient. 5. Data models A. Driver latest location Purpose: hot state for real-time reads Fields: - driver_id - lat - lng - geohash or spatial index key - speed - heading - accuracy_meters - recorded_at from device - received_at from server - sequence_number - active_order_id nullable - status such as idle, heading_to_restaurant, waiting, delivering, offline Store: - Redis for ultra-fast latest-state reads and pub/sub metadata, or DynamoDB/Cassandra for durable scalable key-value storage. - TTL can be applied for stale entries. Key example: - driver_id as partition key B. Driver location history Purpose: analytics and replay Fields: - driver_id - timestamp - lat - lng - speed - heading - active_order_id Store: - Time-series friendly storage, object storage via stream sink, or wide-column database. - Retention can be shorter for raw points and longer for summarized traces. C. Order tracking model Fields: - order_id - customer_id - driver_id - restaurant_id - status such as placed, preparing, driver_assigned, picked_up, en_route, delivered, cancelled - pickup_location - dropoff_location - latest_driver_lat - latest_driver_lng - latest_driver_timestamp - eta_seconds - tracking_visibility boolean - assigned_at, picked_up_at, delivered_at Store: - Primary order record in relational DB or distributed transactional store. - Frequently changing tracking projection in Redis or DynamoDB for low-latency reads. D. Subscription/session model Fields: - connection_id - customer_id - order_id - connected_at - last_heartbeat_at - region Store: - In-memory store such as Redis, or managed WebSocket gateway connection registry. 6. Scaling strategy for peak load Traffic estimation If 50,000 active drivers send updates every 5 seconds on average: - About 10,000 location updates per second at peak. If updates are every 2 seconds during active delivery bursts: - About 25,000 updates per second. This is well within the range of a partitioned event-driven system. Scaling approach A. Stateless horizontal scaling - Scale API Gateway, Ingest Service, and Fanout Service horizontally behind load balancers. - Keep request handling stateless; store session and subscription metadata in shared fast storage. B. Partitioned event streaming - Partition location events by driver_id so ordering is preserved per driver. - Scale consumers by adding partitions and consumer instances. - Separate consumer groups for driver state, customer fanout, ETA, and storage. C. Fast hot-state storage - Use Redis cluster or similar for latest location and order tracking projection. - Keep only current state in cache; use durable systems for source of truth and history. - Use TTL and eviction for stale drivers. D. Region-based deployment - Deploy in multiple geographic regions. - Route drivers to nearest region for ingest to reduce latency. - Keep customer tracking in the same region as the order when possible. - Use cross-region replication only for required metadata, not every raw event globally. E. Backpressure and degradation - If the system is overloaded, coalesce updates and publish only the latest driver position per small time window. - Dynamically reduce update frequency for slow-moving or stopped drivers. - Prioritize active tracked orders over idle-driver telemetry. - Drop clearly stale superseded events in the pipeline. F. Efficient fanout - Push only to the customer associated with the order, not broad geo subscriptions. - Send deltas or compact payloads. - Limit update frequency to what is visually useful, for example 1 to 2 seconds maximum to customer app even if backend receives more frequently. G. Reliability - Use at-least-once delivery in the broker with idempotent consumers. - Deduplicate by driver_id plus sequence_number or timestamp. - Heartbeats detect disconnected customers and offline drivers. - Persist last known snapshot so reconnecting customers can recover immediately. H. Observability Track: - ingest QPS - end-to-end latency from driver send to customer receive - stale location percentage - websocket connection counts - fanout failures and reconnects - per-region broker lag - cache hit ratio Suggested end-to-end architecture - Driver App sends HTTPS location updates. - Global Load Balancer routes to nearest region. - API Gateway authenticates and rate limits. - Location Ingest Service validates and publishes to Kafka. - Driver State Service updates latest location in Redis or DynamoDB. - Order Tracking Service joins with active order assignment and computes tracking payload. - Realtime Fanout Service sends over WebSocket to subscribed customer. - Order Service manages lifecycle transitions. - Historical sink stores raw events in long-term storage. - ETA Service periodically updates ETA shown in customer app. Key design decisions summary - Use HTTPS from drivers for robust mobile ingest. - Use WebSockets to customers for low-latency targeted push. - Use a broker to decouple ingest, state updates, fanout, and storage. - Store latest state in a fast key-value store and historical traces separately. - Scale horizontally with partitioning, regionalization, caching, and adaptive throttling. This design provides low latency, targeted real-time updates, operational simplicity, and enough headroom to support tens of thousands of drivers and hundreds of thousands of tracking customers during peak demand.

# Real-Time Driver Tracking System Architecture ## 1. Driver Location Data Collection Drivers' mobile devices will send location updates at regular intervals (every 5-10 seconds during active delivery). The mobile SDK will: - Capture GPS coordinates with timestamp and accuracy metrics - Buffer updates locally to handle network interruptions - Send batched location data via HTTPS POST requests to a dedicated Location Ingestion API - Implement exponential backoff for failed requests - Reduce frequency when driver is stationary to conserve bandwidth ## 2. Backend Services Architecture **Location Ingestion Service:** - Receives location updates from drivers - Validates data and performs basic filtering - Publishes events to a message queue (Kafka/RabbitMQ) - Returns acknowledgment to mobile client - Scales horizontally with load balancer **Location Processing Service:** - Consumes location events from message queue - Updates driver location in cache (Redis) - Stores location history in time-series database (InfluxDB/TimescaleDB) - Calculates ETA and route optimization - Publishes location updates to notification service **Order Service:** - Maintains order state and driver assignments - Queries current driver location from cache - Tracks order lifecycle events **Notification Service:** - Subscribes to location update events - Determines which customers need updates (based on active orders) - Pushes updates to customers via WebSocket or push notifications ## 3. Customer Location Update Delivery Customers receive real-time updates through: - **WebSocket Connection:** Persistent bidirectional connection for active tracking - **Fallback Mechanism:** HTTP long-polling for clients unable to maintain WebSocket - **Push Notifications:** Periodic updates (every 30-60 seconds) for background tracking When a customer opens tracking: 1. Mobile app establishes WebSocket connection to Location Streaming Service 2. Client sends order ID to subscribe to driver location stream 3. Server validates customer-order relationship 4. Server streams location updates for assigned driver 5. Updates sent only when location changes significantly (geo-fencing) ## 4. Communication Protocol Selection **Primary: WebSocket** - Justification: Persistent connection enables true real-time updates with minimal latency (100-500ms) - Bidirectional communication allows customers to request updates on-demand - Reduces server load compared to polling - Efficient for high-frequency updates **Secondary: MQTT (for driver-to-backend)** - Lightweight protocol optimized for mobile devices - Built-in QoS levels ensure delivery reliability - Automatic reconnection handling - Reduced battery consumption on driver devices **Fallback: HTTP Long-Polling** - For clients with WebSocket limitations - Server holds request open until new data available - Timeout after 30 seconds to prevent resource exhaustion ## 5. Data Models **Driver Location (Cache - Redis):** ``` Key: driver:{driver_id} Value: { driver_id: string, latitude: float, longitude: float, timestamp: unix_timestamp, accuracy: float, speed: float, heading: float, active_order_id: string } TTL: 5 minutes ``` **Location History (Time-Series DB):** ``` Table: driver_locations Columns: - driver_id (indexed) - latitude - longitude - timestamp (indexed) - accuracy - order_id (indexed) Retention: 90 days ``` **Order Information (Primary DB - PostgreSQL):** ``` Table: orders Columns: - order_id (primary key) - customer_id (indexed) - driver_id (indexed) - restaurant_id - status (enum: pending, confirmed, picked_up, in_transit, delivered) - pickup_location (lat, lng) - delivery_location (lat, lng) - created_at - estimated_delivery_time - actual_delivery_time ``` **Active Subscriptions (Cache - Redis):** ``` Key: subscriptions:{order_id} Value: Set of {customer_connection_id} TTL: Order completion + 1 hour ``` ## 6. Scaling Strategy **Horizontal Scaling:** - Location Ingestion: Deploy multiple instances behind load balancer (target: <100ms p99 latency) - Location Processing: Kafka consumer groups with partition-per-driver strategy - WebSocket Servers: Sticky sessions with Redis for connection state - Database: Read replicas for location queries, write to primary **Caching Strategy:** - Redis cluster for driver locations (in-memory, <10ms access) - Cache warming: Pre-load active driver locations on service startup - Geo-spatial indexing in Redis for proximity queries **Database Optimization:** - Time-series database for location history (optimized for time-range queries) - Partitioning by date for location history tables - Indexes on (driver_id, timestamp) and (order_id, timestamp) - Archive old data to cold storage after 90 days **Message Queue Tuning:** - Kafka with 100+ partitions for location events - Consumer group per service type - Batch processing: 1000 messages or 5-second window **Peak Load Handling (50K drivers, 200K customers):** - Expected location updates: 50,000 drivers × 1 update/10s = 5,000 updates/second - Expected WebSocket connections: 200,000 customers (assume 30% active tracking = 60,000 concurrent) - Ingestion capacity: 10,000+ updates/second per instance (3-5 instances) - WebSocket servers: 60,000 connections ÷ 10,000 per server = 6-8 servers - Message queue throughput: 10,000+ messages/second **Monitoring & Alerting:** - Track p50, p95, p99 latencies for location updates - Monitor queue depth and consumer lag - Alert on WebSocket connection failures - Track database query performance - Implement circuit breakers for cascading failure prevention **Cost Optimization:** - Use CDN for static assets - Implement location update throttling based on driver speed - Compress location data in transit - Use spot instances for non-critical services during off-peak