Design an IoT Analytics Platform

Problem statement

Design an IoT analytics platform that collects telemetry from millions of intermittently connected devices, validates and enriches every reading, computes streaming rollups and anomaly alerts, stores history across hot, warm, and cold tiers, and serves real-time dashboards, ad-hoc queries, and device actions. The platform must tolerate devices with drifting clocks, lossy cellular or LPWAN links, reconnect storms after regional outages, and hostile actors attempting to spoof device identity.

This is not one database with an HTTP endpoint. The write path is append-only, massively skewed, and arrives from the least trustworthy computers you own: field devices you cannot patch quickly. The read path splits into three incompatible workloads: second-freshness operational dashboards, interactive range queries over weeks, and batch scans over years of archived readings. Forcing all three through one engine is the classic failure of this problem.

Why the problem is distinctive

A web backend retries a failed request; an IoT platform frequently cannot ask the device to resend, because the device is battery-bound and may be asleep for an hour. Acknowledged data must therefore be durable. Meanwhile time itself is data: a reading generated at 09:00:00 may arrive at 09:14:37 after a connectivity gap. Windowed aggregation must key on event time with explicit late-data policy, or every alert threshold silently becomes wrong.

The second killer is cardinality. A series is typically (tenant, device, metric, tag-set). Ten million devices, twenty metrics, and three tag dimensions with ten values each can produce billions of distinct series. Time-series stores die from series count long before they die from byte volume. The design must treat series cardinality as a governed budget, not an accident.

Public operating baseline versus design assumptions

Public evidence establishes that this category operates at extreme scale. Netflix publicly describes its Keystone stream platform processing on the order of hundreds of billions of events per day with multi-million-events-per-second peaks. LinkedIn publicly reports Kafka-class message volumes in the trillions of messages per day across its activity pipelines. Uber publicly describes petabyte-scale daily ingestion into its data platform. MQTT, the dominant IoT transport, was created in 1999 by Andy Stanford-Clark and Arlen Nipper for monitoring oil pipelines over satellite links, which explains its design for intermittent, bandwidth-constrained links. These are cited context, not requirements for our fictional system.

For capacity planning, this answer explicitly assumes a mature platform with 10 million registered devices, 2 million simultaneously connected, 1 million telemetry messages per second average, and a five-times event peak. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold.

The four architectural planes

1. Device and edge plane: SDKs and gateways, local buffering, store-and-forward, optional pre-aggregation, protocol adaptation.
2. Ingestion plane: MQTT/HTTP brokers, device authentication, topic and rate authorization, schema validation, routing into the stream backbone.
3. Stream processing plane: durable log, windowed aggregation, enrichment, anomaly detection, alert evaluation, fan-out to multiple consumers.
4. Serving and control plane: time-series store, lakehouse archive, query service, dashboards, alert notification, device twins, commands, and policy.

A strong interview answer keeps these planes separate. Ingestion may shed load without corrupting acknowledged data, processing may lag without blocking writes, and the serving tier may degrade freshness without losing history.