IoT telemetry platform architecture.
Assume every device is offline, on a bad network, running firmware from two years ago, and cannot be recalled. The architecture follows from that.
The components
Every row below is read from the graph that produced the diagram above, so the two cannot disagree.
| Component | Tier | Why it is there |
|---|---|---|
| Devices | Client | Intermittent connectivity is the normal case |
| MQTT broker | Edge | Long-lived sessions, QoS 1 at least |
| Ingest gateway | Edge | Supporting component |
| Device identity | Application | Per-device certificates, revocable |
| Decoder | Application | Binary payloads to typed readings |
| Rules engine | Application | Thresholds and alerts on the stream |
| Device shadow | Application | Last known state, readable while offline |
| OTA updates | Application | Staged rollout, because a bad firmware bricks the fleet |
| Kafka | Data | Supporting component |
| Time series DB | Data | Downsampled by age |
| Cold storage | Data | Supporting component |
| Grafana | Infrastructure | Supporting component |
Design decisions worth arguing about
A diagram shows what was chosen. It does not show what it cost, and that is usually the part that matters in a review or an interview.
MQTT rather than HTTP
A persistent connection with small framing suits devices that are power-constrained and behind NAT, and it lets the platform push to them, which HTTP polling cannot do cheaply. The cost is a broker to operate, session state per device, and a connection count that becomes the platform's main scaling dimension rather than request rate.
Device shadows, because the device is usually unreachable
Applications need to read device state and set desired state at times when the device is asleep or out of coverage. A shadow holds last-reported and desired state so both work regardless, and the device reconciles on reconnect. The consequence is that every application is reading data that may be hours old, and the interface has to make that visible rather than pretending it is live.
Per-device credentials, individually revocable
A shared secret across a fleet means extracting it from one device compromises all of them, and rotating it means touching every device. Per-device certificates make revocation surgical. The cost is a provisioning process and a certificate lifecycle to manage across a fleet that may outlive the team that deployed it.
Staged firmware rollout, because a bad update is unrecoverable
Software you can roll back; firmware that bricks a device requires physical access. Rolling out to a small cohort, watching for devices that fail to check in, and only then continuing is the only real protection. It makes updates slow, which is the correct speed for an operation with no undo.
How it changes with scale
Ingest scales with device count times reporting frequency, and reporting frequency is usually the cheaper thing to change. Time series storage grows without bound unless downsampled, so retention tiers should be designed at the start: full resolution briefly, aggregates for a long time, raw archived to cold storage for the rare audit.
Where it breaks first
A reconnect storm after a network or broker outage. Every device attempts to reconnect at once, and each reconnect involves a handshake far more expensive than a telemetry message. Without jittered backoff in the firmware, and firmware is the part you cannot change quickly, the platform cannot recover under its own load.
Draw this yourself
Open the Diagram tab and describe the system. The agent emits a semantic graph rather than coordinates, so you can edit the components and the layout re-solves instead of drifting.
When the shape is right, Implement in code turns the canvas into a markdown specification, every component, every relationship and the notes, and starts a real turn in the Code tab with it.
Questions about this design
More templates
- URL Shortener System DesignThe canonical read-heavy system: roughly a hundred reads for every write, and a redirect that has to be fast enough that nobody notices it happened.
- Chat Application System DesignLong-lived connections change everything: the hard part is not storing messages, it is knowing which of your servers is holding the socket you need to write to.
- Payment System DesignThe only system on this list where being approximately right is indistinguishable from being wrong, and where the provider, not you, holds the truth.
- RAG Pipeline ArchitectureAlmost every RAG system that disappoints is failing at retrieval, not generation, and the architecture is what decides whether you can tell.