Design a Real-Time Vehicle Tracking System

Streaming Telemetry Architecture

The write path is optimized for high volume streaming telemetry. MQTT keeps 10M persistent vehicle connections lean, Kafka buffers bursts, and Flink validates and fans out updates to Redis for live lookups and TimescaleDB for historical trails. Dashboard operators subscribe over WebSocket channels to receive real time updates without polling.

Telemetry flows from vehicle sensors through the gateway into streaming processors. The processors update live state in Redis and push deltas over WebSockets. Compare with streaming patterns in Stream Processing Basics.

Connection Gateway: Handling 10M Persistent Connections

MQTT vs HTTP for vehicle GPS: HTTP requires approximately 4 KB of overhead per update. Across 12 updates per minute and 10M vehicles, the assumed headers alone total roughly 690 TB per day. MQTT ⭐: Persistent connections with a 20-byte header and 100-byte payload require only 120 bytes per update, reducing the transport payload estimate to approximately 21 TB per day. QoS 1 provides at least once delivery. Reconnection logic handles tunnel transitions, while Last Will and Testament publishes an offline event after the broker detects an unexpected disconnect.

MQTT Broker Cluster (EMQX or VerneMQ): Using approximately 200K concurrent connections per broker as a starting capacity assumption gives about 50 broker nodes for 10M vehicles. Benchmark connection churn, message rate, memory usage, and failover behavior before fixing the production node count.

Location Processor: Updating Latest Position in Redis

A Flink streaming job consumes from the Kafka vehicle-locations topic, validates coordinates, deduplicates points by event_id, enriches telemetry with fleet metadata, writes to Redis via HSET under vehicle:{vehicle_id}, refreshes a separate vehicle_connectivity:{vehicle_id} key from broker session state, and publishes to geohash scoped Redis Pub/Sub channels for dashboard distribution. The latest position key can expire after 5 minutes as a stale telemetry guard, while connectivity state distinguishes GPS_LOST from a disconnected vehicle. Because Redis Pub/Sub is ephemeral, clients can refresh current state through the REST endpoint after reconnecting.

Movement Status Detection: Speeds above 5 km/h indicate moving. Speeds below 2 km/h for more than 5 minutes indicate parked. Speeds from 2 through 5 km/h are treated as idling unless a domain rule says otherwise. A separate connectivity key derived from MQTT session heartbeats distinguishes GPS_LOST from offline status when the vehicle remains connected but stops sending GPS points.

Trail Writer: Persisting Location History

Storage choice: TimescaleDB serves the recent 90 day trail tier with time based partitioning, 10 to 20 times compression, SQL querying, PostGIS integration, and continuous aggregates. ClickHouse serves the cold tier for 2 or more years of aggregate analytics.

Batch writing: Flink accumulates location points and executes bulk inserts into TimescaleDB every 5 seconds. Processing 2M points per second across a 5 second window yields 10M rows per batch, which distributes across 4 shards at 2.5M rows per shard, with an under 1 second completion target that must be validated by load testing.

Dashboard: Real Time Fleet View

Fleet operators connect via WebSockets to backend servers that subscribe to geohash scoped Redis Pub/Sub channels. Initial page loads use the fleet vehicle index in Redis to fetch current positions. Viewport filtering ensures servers transmit only vehicles falling within active map coordinates, while client side libraries handle clustering at lower zoom levels. When a dashboard reconnects after a missed Pub/Sub event, it refreshes current state through the REST API.

Event Bus Design (Kafka)

Topic: vehicle-locations
  Partitions: 512 (illustrative starting point for 2M updates/sec)
  Partition key: vehicle_id
  Retention: 48h (replay after TimescaleDB or Flink recovery)
  Replication factor: 3, min.insync.replicas: 2

Producer: MQTT broker bridge (idempotent producer)
  Event: { event_id, vehicle_id, lat, lng, speed, heading, timestamp, events[] }

Consumer groups:
  1. location-processor: Flink: validate, dedup, update vehicle:{id} in Redis (5-min TTL)
     Publish to fleet:{fleet_id}:geo:{geohash_prefix} for dashboard WebSocket fan out
  2. trail-writer: batch INSERT into TimescaleDB location_points hypertable
  3. alert-engine: geofence breach, speed > 300 km/h, idle > 30 min -> vehicle-alerts topic

Topic: vehicle-alerts (64 partitions) -> Notification Service (push, webhook)
Topic: vehicle-status-changes (64 partitions) -> fleet management integrations

Ingest path: broker ACK < 100ms after durable acceptance, with the Kafka bridge retrying independently
Hot read path: dashboard reads current position from Redis
Async path: trail history, alerts, and analytics never block GPS ingest
DLQ: vehicle-locations-dlq after 3 retries, with an alert when consumer lag > 60s
Recovery: replay Kafka to rebuild Redis latest state after cache loss