Deploying IoT Where the Network Is Unreliable

Most IoT tutorials assume a stable connection. In the deployments I've worked on, that assumption is the first thing to go.

When a device is on a satellite link with intermittent availability, or a cellular connection metered by the megabyte, the design constraints invert completely.

Constraint one: assume every message may not arrive

If the link drops, you have two choices: buffer locally and retry, or lose the data. For anything that matters, it has to be the first.

This means the device needs local storage and a queue that survives a power cycle. In practice:

• Write to local storage before attempting to transmit
• Only remove on confirmed acknowledgement
• Bound the queue so a long outage doesn't fill the disk — and decide deliberately what gets dropped when it's full

Constraint two: bandwidth is a budget

On a metered link, every byte has a cost and a power implication. The instinct to report every reading every second is usually wrong.

What works better is edge filtering — the device decides what's worth sending. Report on change, report on threshold crossing, and send a periodic heartbeat so you can distinguish "nothing to report" from "device is down." Those two states look identical if you only send on events.

Constraint three: the device must survive alone

Remote sites mean a site visit costs hours. Devices need to recover from faults without a human:

• Watchdog timer that reboots the device if the main loop hangs
• Fail-safe state — decide what happens when the link is down, rather than leaving it undefined
• Config that survives a firmware update, so a failed update doesn't require re-provisioning

Constraint four: time is unreliable too

Devices without a real-time clock or NTP will drift, and worse, they'll reset to epoch on reboot. Timestamps from an unreliable device are a trap — data that looks plausible but is silently wrong.

The fix is to treat device time as a hint and timestamp on ingestion, or sync properly and record the sync status alongside the reading so you know which timestamps to trust.

The design principle underneath

Design for the link being down, and everything else follows. Once you assume the network is a rare privilege rather than a constant, the architecture stops being about real-time streaming and becomes about durability and reconciliation — which, it turns out, is a more honest model for most distributed systems anyway.