IoT Networks and Telemetry Platforms: Implementation and Operational Experience

When most organizations imagine an IoT project, they picture a controlled pilot: a dozen sensors on a test bench, a dashboard on someone's laptop, and a proof-of-concept that runs for a few weeks. That image is useful for securing budget, but it has very little to do with how IoT behaves in production. The moment a deployment moves from the lab to the field — across factories, utility networks, agricultural plots, logistics fleets, or municipal infrastructure — the number of connected assets jumps from dozens to thousands or tens of thousands. At that scale, the engineering problem changes shape entirely. It stops being about reading a sensor and becomes about operating a distributed system that never stops talking.

At OneDev we build and operate telemetry platforms for industrial and public-sector clients in Uzbekistan, and the lessons below come from the operational reality of running fleets at scale rather than from vendor marketing. This article walks through what actually breaks, what to design for from day one, and how to make a telemetry platform survive its second and third year in production.

Why scale changes everything

A pilot with 20 devices is forgiving. If a message is lost, you notice and resend it. If a device clock drifts, you correct it by hand. If the database slows down, nobody dies. None of that holds at 20,000 devices. The system stops being something you observe and becomes something you have to engineer for failure, because failure is now continuous and statistical rather than occasional and visible.

Consider message volume. A single sensor reporting once per minute is trivial. Ten thousand sensors reporting once per minute is roughly 167 messages per second, every second, forever — and that is the calm baseline. Real fleets are bursty: a network outage reconnects thousands of devices simultaneously, each flushing a backlog of buffered readings. A platform sized for the average load will fall over during these reconnection storms, which is exactly when the data matters most.

The second shift is heterogeneity. A pilot uses one device model with one firmware version. A production fleet accumulates generations of hardware, firmware revisions that were never fully rolled out, devices on cellular and devices on Wi-Fi, and units that have been in the field long enough to behave in ways nobody documented. The platform has to ingest all of them without a special case for each.

Ingestion and protocols: the front door

The ingestion layer is where most telemetry platforms succeed or fail. Protocol choice is the first decision, and it is rarely one-size-fits-all. MQTT remains the workhorse for constrained devices and unreliable links because it is lightweight, supports persistent sessions, and handles intermittent connectivity gracefully through QoS levels and retained messages. HTTP/REST is simpler to integrate and firewall-friendly but expensive per message and poor at push. CoAP suits very constrained, low-power nodes. Many real deployments end up running more than one protocol behind a normalization layer.

Whatever protocol you choose, the ingestion endpoint must be horizontally scalable and stateless where possible, with a message broker or queue immediately behind it to decouple acceptance from processing. The golden rule: accept fast, process later. Devices should never wait on your database. The endpoint acknowledges the message, drops it onto a durable queue, and lets downstream consumers handle parsing, validation, and storage at their own pace. This single architectural choice is what lets a platform absorb reconnection storms instead of collapsing under them.

Time, identity, and the data you actually trust

Two problems quietly poison telemetry platforms, and both come from trusting the device too much: time and identity.

Device clocks lie. They drift, reset to factory defaults, jump to the future after a firmware update, or report in a timezone nobody configured. If you index and filter your data purely by the timestamp the device reports, you will lose real readings that arrive with impossible dates and you will see gaps that are not gaps. The reliable fix is to record two timestamps for every reading: the device-reported time and the server-received time. Query and partition primarily by the server-received time, keep the device time for analytics, and flag readings where the two diverge beyond a threshold. This is not a theoretical concern — we have seen production fleets where a meaningful fraction of valid data carried timestamps years off, silently disappearing from dashboards because filtering was done on the wrong clock.

Identity is the second trap. Every device must have a strong, unique, provisioned identity — ideally backed by per-device credentials or certificates, not a shared key baked into firmware. A shared secret across a fleet means one extracted credential compromises everything, and revoking it bricks every device at once. Per-device identity also makes it possible to deprovision a stolen or decommissioned asset cleanly, attribute every message, and rotate credentials without a fleet-wide outage.

Storage, retention, and making data useful

Telemetry is append-heavy, time-ordered, and enormous. A general-purpose relational table will work in the pilot and become a liability at scale. Time-series databases or time-partitioned storage are designed for this access pattern: high-rate inserts, time-range queries, and automatic aging of old data. Equally important is a deliberate retention policy. You almost never need raw second-by-second data forever. A common, defensible strategy is to keep raw data hot for a short window, downsample to aggregates (hourly or daily rollups) for the medium term, and archive or discard the rest. Decide this before launch, because retrofitting retention onto a multi-terabyte table under load is painful.

Operating the fleet: the part nobody budgets for

Building the platform is half the work. Operating thousands of devices over years is the other half, and it is consistently underestimated. A production IoT platform needs answers to operational questions that a pilot never asks.

• Fleet observability. You need to know not just what data arrived, but which devices have gone silent, which are reconnecting abnormally often, and which are reporting degraded readings. A device that stops sending data produces no error — it simply produces nothing, which is the hardest failure to notice. Build "expected silence" detection, not just error alerting.
• Over-the-air updates. Firmware will need updating, and a fleet you cannot update remotely is a fleet of future on-site visits. OTA must be staged, reversible, and able to survive devices that lose power mid-update.
• Backpressure and graceful degradation. When a downstream component slows, the platform should shed or buffer load predictably rather than cascade into a full outage. Decide in advance what you drop first.
• Provisioning and decommissioning at scale. Onboarding 5,000 devices by hand is impossible; the lifecycle has to be automated end to end, including clean removal.

Security is not a layer you add later

An IoT network is a large, physically exposed attack surface. Devices live in the field where attackers can touch them, and a compromised fleet can be turned into a botnet or a data-exfiltration channel. The non-negotiables are transport encryption (TLS everywhere, including device-to-broker), per-device authentication, the principle of least privilege so a device can only publish to its own topics, and network segmentation so the IoT plane cannot reach back into core business systems. For public-sector and critical-infrastructure deployments in Uzbekistan, this also intersects with data residency and regulatory expectations, which should be settled at the architecture stage rather than discovered during an audit.