A Complete Guide to IoT Backends: MQTT, WebSocket, and Multi-Protocol Telemetry
A Complete Guide to IoT Backends: MQTT, WebSocket, and Multi-Protocol Telemetry
An IoT backend has one hard job: take messy, real-world device data — arriving over different protocols, at different rates, with different reliability — and turn it into one trustworthy view. This guide explains how, based on freelance IoT work connecting 8+ device categories (water, kWh, and gas meters, nurse call, code blue, panic buttons, smart locks, vending machines, and factory PLCs) across Modbus, MQTT, BLE, and WebSocket.
If you want one built, see the IoT backend development service; for the real project, see the case study.
The core challenge: every device speaks a different language
Water meters use Modbus RTU. Factory PLCs talk Modbus TCP. Short-range sensors need BLE. Urgent alerts arrive over MQTT and WebSocket. Operators should not have to care about any of that. The backend's job is to hide protocol differences behind one common data model.
The shape is always the same: per-protocol adapters feed a normalization layer, which writes one canonical telemetry model that everything downstream reads.
Push vs poll: two fundamentally different device types
IoT devices fall into two camps, and the backend must handle both:
- Event-driven (push) — MQTT and WebSocket devices send data when something happens. The backend subscribes and reacts. Great for alerts and low-latency updates.
- Polled (pull) — Modbus devices don't push; the backend must ask them on a schedule and read their registers. Great for meters that report steady values.
Mixing them well is most of the work. More on this in Modbus Polling vs Event-Driven Ingestion.
MQTT vs WebSocket: not the same thing
People lump MQTT and WebSocket together, but they solve different problems. MQTT is a lightweight pub/sub protocol built for constrained devices and many-to-many messaging; WebSocket is a persistent browser-to-server channel ideal for pushing live updates to a dashboard. Most real systems use both — MQTT to ingest from devices, WebSocket to deliver to screens. The full comparison is in MQTT vs WebSocket for Real-Time IoT.
Normalize, then store
Once data is normalized, two storage jobs follow. A fast in-memory store (Redis) holds the current live state — what each device is doing right now — so the dashboard updates instantly. A durable store (PostgreSQL) keeps history for reporting, trends, and audits. Keeping the hot path and the cold path separate is what keeps dashboards snappy without losing history. See Unifying Multi-Protocol Devices for how the normalization layer is structured.
Don't forget connection health
A silent device looks the same as a healthy one reporting steady values — until you realize the data is stale. A good IoT backend tracks last-seen timestamps and surfaces connection health on the dashboard, so a dead Modbus link or a dropped MQTT session is visible, not hidden behind an old reading.
Build the dashboard around the workflow
The biggest lesson from real deployments: design the dashboard around what the team actually does, not around the devices. A nurse-call alert needs to arrive instantly and unmissably; a kWh meter just needs a clean trend. Same backend, very different presentation — and the presentation should follow the operator's job.
Where to go next
If you have devices across different protocols and want one real-time view, see the IoT backend development service, read the case study, or get in touch.