Design an IoT Device Control Panel

Problem statement

Design an IoT device control panel: a web and mobile console that lets operators monitor thousands to millions of connected devices — smart lights, thermostats, sensors, locks, plugs — grouped by site, room, and type; stream their telemetry in near real time; and send actuation commands such as on/off, brightness, temperature setpoint, or lock/unlock with visible confirmation.

This is not a chat system and not a metrics dashboard. It is a bidirectional control surface over physically consequential devices. A delayed chat message is an annoyance; a stale 'unlocked' indicator on a door lock is a security incident; a lost 'lights off' command to a warehouse with 4,000 fixtures is a real cost. The design therefore separates three loops that many candidates collapse into one:

1. Telemetry loop (device to console): devices publish sensor readings and status; the platform ingests, orders, stores, and fans them out to subscribed consoles.
2. Command loop (console to device): an operator issues intent; the platform authorizes, persists, delivers, and confirms it — including when the device is offline.
3. Presence loop (mutual): both sides must know whether the other is alive, and how stale every number on screen is.

Why this problem is hard

Consumer devices sit on unreliable home Wi-Fi behind NAT, sleep to save battery, and reconnect in correlated storms after a power cut. The console must show current truth for 250 devices on one screen while 600,000 devices publish upstream. Commands must be idempotent, authorized, and safe to retry. The panel must degrade honestly: a stale value with a visible age marker beats a fresh-looking wrong value.

AWS documents its device shadow pattern precisely because naive request/response fails on unreliable links: a shadow holds desired state in the cloud and reconciles it with reported state from the device, so a command survives the device being asleep. Azure IoT Hub documents the same idea as device twins plus direct methods with acknowledgement payloads. Both platforms independently converged on 'persist intent, reconcile later' as the correct primitive. Our design does the same.

Assumed operating baseline

For capacity planning this answer assumes a commercial smart-building deployment: 10,000 sites, 1,000,000 registered devices, 600,000 online at peak, 20,000 telemetry messages per second average with a 5x event peak, 500,000 commands per day, and 20,000 concurrent console sessions. Unless tied to a named public figure, every number in this answer is an explicit design assumption, target, or budget.

The five architectural planes

1. Device edge plane: firmware runtime, MQTT client, local state cache, store-and-forward buffer, secure element.
2. Connectivity plane: mutually authenticated MQTT broker fleet, topic ACLs, presence registry.
3. Platform plane: device registry, device shadow/twin service, command service, rules/schedules engine.
4. Data plane: event stream, latest-value cache, time-series store, audit ledger.
5. Experience plane: console REST API, WebSocket fanout gateway, role-based views.

A strong answer keeps these planes separate. Telemetry may degrade without weakening command delivery, and command delivery must never depend on the console being connected.