IoT Backends: MQTT, WebSocket, and Device Data
Ingesting MQTT, WebSocket, Modbus, and BLE telemetry, then normalizing it into one real-time data model.
For Business

On this page
An IoT backend collects device data so a team can monitor conditions, review history, and handle faults from one place. IoT refers to physical devices connected to a data system. 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 may use Modbus RTU over a serial cable; factory programmable logic controllers (PLCs) may use Modbus TCP over a network. Some short-range sensors use Bluetooth Low Energy (BLE). Alerts can arrive through MQTT messaging or a persistent WebSocket connection.
Operators should not have to handle those differences individually. The backend translates each protocol into one common data model, so device conditions appear in a consistent view.
In this design, 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
These integrations use two main patterns, and the backend needs to 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 publish/subscribe protocol, where devices send messages through a broker to interested subscribers, 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 can retrieve live state quickly. A durable store (PostgreSQL) keeps history for reporting, trends, and audits.
Separating live updates from historical queries helps keep dashboards responsive while retaining records for reports. 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 a tested response time and a display staff can recognize immediately. 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.
Related Posts
Need help applying this approach?
IoT Device Monitoring System Development
Bring meter, sensor, and other device data into one dashboard. Monitor recent readings, historical data, and disruptions around your operational needs.
Explore related servicesDescribe the operational problem you are facing so we can discuss a suitable next step.