Most IoT projects spend months on firmware and a week on the backend. Then the backend becomes the reason the product feels unreliable. A small, well-chosen architecture avoids that.
The building blocks
| Layer | Job | Typical choice |
|---|---|---|
| Device connectivity | Receive messages, authenticate devices | MQTT broker with TLS and per-device credentials |
| Storage | Keep readings with timestamps | Time-series database with retention rules |
| Video | Deliver live streams and recordings | Media server: RTSP in, WebRTC or HLS out |
| Dashboards and alerts | Show fleet health, notify on problems | Dashboard tool plus alert rules |
| Device management | Configuration and firmware updates | Retained messages or device shadows, OTA service |
Design rules that prevent pain later
One identity per device
Never share credentials across devices. You must be able to revoke one unit.
Buffer on the device
Devices should store readings while offline and upload with timestamps when back.
Agree on message formats early
Version your payloads so firmware and server can evolve independently.
Plan retention
Decide how long raw data is kept before storage costs surprise you.
Monitor the backend too
Alert when ingestion drops, not only when devices misbehave.
Frequently asked questions
Should I use a cloud IoT platform or self-host?
Managed platforms are faster to start. Self-hosting gives more control and lower running costs at scale. Both can use the same device-side design.
How do I stream video from devices behind NAT?
Devices push streams outward to a media server, which then serves viewers. No inbound ports on the device.
How many devices can one server handle?
Hundreds to thousands for telemetry on modest hardware, depending on message rates. Video needs far more capacity.
Embedded systems consultant at TechProgeny, Bengaluru. 7+ years and 29+ shipped products across firmware, embedded Linux, edge AI, apps and IoT servers.