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 and turn it into one trustworthy view. That data arrives over different protocols, at different rates, with different reliability. This guide explains how, based on freelance IoT work connecting 8+ device categories across Modbus, MQTT, BLE, and WebSocket. Those categories span water, kWh, and gas meters, nurse call, code blue, panic buttons, smart locks, vending machines, and factory PLCs.

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 shouldn't have to care about any of that. Think of a travel adapter that turns every kind of plug into one shape every device accepts. 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. Good for alerts and low-latency updates.
• Polled (pull) — Modbus devices don't push. The backend has to ask them on a schedule and read their registers. Good for meters that report steady values.

Mixing the two 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. A field-tested walkthrough of the two together is in building MQTT and WebSocket backends 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. That way, 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. For more on tying multiple systems into one operational view, see building dashboards that connect different systems.

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.