Design an IoT Fleet Monitoring & Analytics

Problem statement

Design an IoT fleet monitoring & analytics platform that tracks hundreds of thousands of vehicles and mobile assets, continuously ingesting high-frequency location pings and sensor data, showing near-real-time positions on fleet-manager dashboards, detecting anomalies such as speeding, harsh braking, and route deviation as they happen, replaying historical routes, and producing daily usage analytics for operations and billing.

The brief requires high-frequency location pings and sensor data, real-time dashboards for fleet managers, route replay and anomaly detection such as harsh braking, and summaries or daily usage analytics. It also requires scalability for large fleets with constant updates, low-latency near-real-time positions, reliability when devices go offline, and edge caching when the network is spotty.

Why the problem is distinctive

A web application can hide latency behind a loading spinner. A fleet operations room cannot: a dispatcher watching a live map expects a vehicle marker to move within one or two seconds of the vehicle actually moving, and a safety team expects a harsh-braking alert within seconds, not after the nightly batch. At the same time, the platform must store years of per-second telemetry for route replay and usage reporting. That combination makes this a three-speed system: a fast lane for live state and alerts measured in seconds, an operational lane for trips, duty status, and incident workflow measured in minutes, and an analytical lane for daily rollups, route optimization, and long-term retention measured in hours and days. Designs that collapse all three speeds into one pipeline either overload the transactional store with time-series writes or make the dashboard minutes stale.

The attached brief emphasizes that most preparation resources treat this question shallowly and that the differentiator is advanced fleet analytics such as driving behavior and route optimization, plus concurrency, ephemeral device pings, and big-data aggregation. This answer treats those as first-class architecture problems rather than features bolted onto a CRUD backend.

Public operating baseline versus design assumptions

Public evidence shows the category operates at serious scale. Geotab publicly reports more than 2.8 million connected vehicles and tens of billions of data points processed per day as company figures. Samsara publicly reports tens of thousands of customers and tracking trillions of data points annually. Cambridge Mobile Telematics publicly reports tens of billions of miles of driving data scored across insurer programs. These are company-reported public figures used as context, not design targets for our system.

For capacity planning, this answer explicitly assumes a mature multi-fleet platform with 500,000 registered vehicles, 200,000 simultaneously active, roughly 27,000 telemetry messages per second average, 150,000 messages per second provisioned peak, and 3 million trips per day. Unless a number is tied to a named company disclosure, it is a stated design assumption, target, budget, or illustrative threshold.

The four architectural planes

1. Ingestion plane: device identity, MQTT/AMQP gateways, envelope validation, sequencing, deduplication, and store-and-forward reconciliation.
2. Live and operational plane: per-vehicle latest state, geospatial indexes, dashboard fan-out, trip segmentation, and command delivery.
3. Alerts and analytics plane: streaming rule evaluation, anomaly detection, alert lifecycle, daily rollups, route replay, and the data lake.
4. Governance plane: schema and rule versioning, retention and privacy policy, device certificate lifecycle, audit, and release management for detection models.

A strong interview answer keeps these planes separate: the dashboard may degrade to stale markers while ingestion never loses a safety-relevant message, and a new anomaly model may be canaried without changing the ingest contract.