System Design Interview
IoT telemetry platform inspired by AWS IoT Core and Azure IoT Hub: MQTT brokers with certificate authentication, a telemetry stream feeding time-series storage, device shadows, a rules engine for alerts, and downsampled cold archives. A teaching design.
See why one request and one row per reading can't serve millions of devices.
What was missing: Nothing yet.
Why that's risky: New TLS connections per reading drain device batteries and the server; 100K inserts per second plus dashboard scans overwhelm one database.
What gets added: One server where each device posts a reading over HTTP and it is inserted as a row, with dashboards querying the same table.
Trade-offs: Simple, but neither the protocol nor the storage fits small, frequent readings.
Keep devices connected cheaply, buffer their readings, and store them in a time-series format.
What was missing: One HTTP request and one row per reading.
Why that's risky: 'What is this device doing now?' scans recent history every time, and dashboards hit the database directly.
What gets added: MQTT brokers holding a persistent connection per device and authenticating it by certificate against a thing registry, a durable telemetry stream partitioned by thing, storage writers that batch readings into a compressed time-series database, and a query service on its own path.
Trade-offs: Readings become queryable a few seconds after they're published, in exchange for ingestion that never waits on storage.
Answer 'latest state' instantly and stop dashboards from rescanning history.
What was missing: Latest state required a history query, and repeated dashboard queries recomputed everything.
Why that's risky: Nothing notices when a device reports something dangerous or goes silent.
What gets added: A shadow updater that keeps each thing's latest state in a shadow store, and a query cache for recent time windows.
Trade-offs: The shadow is eventually consistent with the stream, typically within a second.
Detect anomalies and silent devices as data arrives and notify the right people.
What was missing: No detection or alerting.
Why that's risky: All history stays in the hot database forever, so cost and query time keep growing.
What gets added: A rules engine that evaluates each reading from the stream (thresholds, rate of change, missing heartbeats), an alert queue, and a notifier that sends deduplicated alerts by push, SMS or webhook.
Trade-offs: Rules see each reading once as it streams by; rules over long windows need state kept per thing.
Keep years of history cheaply and keep long-range queries fast.
What was missing: Raw readings were kept forever in the hot database.
Why that's risky: One misbehaving device model can still flood the brokers, and nobody watches pipeline lag.
What gets added: A downsampler that rolls readings into 1-minute and 1-hour aggregates and archives data older than 30 days as compressed columnar files in object storage.
Trade-offs: Old data loses per-reading detail; the archive keeps raw files for audits.
Contain misbehaving devices and watch the pipeline.
What was missing: No per-device limits and no view of pipeline health.
Why that's risky: Remaining risk is regional: devices should fail over to brokers in another region.
What gets added: A per-thing publish quota at the edge and monitoring of connected things, ingest lag, stream backlog and rule delay.
Trade-offs: A device over quota has readings dropped until it slows down; it's told why.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
