A practical guide to reliability between the device, the edge and the cloud.

A temperature sensor in a factory records a measurement at 02:13. The local system is running, the measurement is valid, but the internet connection is down. Connectivity returns several hours later.

What happened to that measurement in the meantime?

It may have been stored locally and sent later. It may have disappeared during a restart. It may be sent twice because the sender never received an acknowledgement (ACK). It may arrive safely in the cloud at 08:17 and suddenly look like a measurement from 08:17 rather than 02:13.

This is not an unusual IoT scenario. It is simply the part that tends to disappear inside the arrow between a device and a cloud.

An event may pass through a local application, MQTT, an edge service, an internet connection, cloud ingestion and finally another application or API. Each of those components can fail independently.

Which leads to a useful question:

Who owns the event now?

That question explains a large part of IoT reliability.

Offline is normal

Vehicles lose coverage. Factories have network interruptions. Remote installations can be disconnected for hours.

A local system may continue working perfectly while the cloud is unavailable.

If the events produced during that period matter, they need somewhere safe to live until they can move on.

That usually means accepting them locally first.

Once you do that, however, you have a new set of responsibilities. The event needs to survive a restart. Local storage cannot grow forever. A backlog needs to be sent when connectivity returns. If the connection disappears again halfway through, the system needs to continue from somewhere sensible.

And if a send succeeds but the ACK never comes back, you may have to send the same event again.

This is where retry logic starts turning into infrastructure.

A basic implementation might begin with ten lines of code. Retry a failed request. Then add backoff. Then persistence. Then event IDs for duplicate handling. Then restart recovery.

Sooner or later, somebody also needs to know what is sitting in the backlog and why.

For more on the offline side, see Your IoT Application Shouldn't Depend on the Cloud Being Online and What Happens to Your Telemetry When the Internet Disappears?

Who owns the event?

Lost acknowledgements are a good example of why this question matters.

The receiver gets the event and processes it successfully. The acknowledgement disappears on the way back.

The sender cannot know that, so it retries.

Now the receiver sees the same logical event twice.

The event therefore needs an identity, and both sides need to understand that a second delivery attempt is still the same event. Lost ACKs: The Failure Nobody Thinks About looks more closely at that case.

But the underlying problem is ownership.

Before the application has handed the event to anything else, the application owns it. Responsibility should only move when the next component has accepted the event in a way that survives a crash or restart.

For example:

Application owns event → Edge persists event → Edge owns event

Later:

Edge owns event → Cloud accepts event → Cloud owns event

Eventually:

Cloud owns event → Destination accepts event → delivery is complete

If a local service returns success before the event has been persisted, responsibility has not safely moved.

And if the application still keeps its own copy after every successful publish because it does not trust the next component, responsibility has not really moved either.

We call this event custody. Who Owns the Event? Understanding Durable Event Custody goes deeper into the model.

Delayed data has another problem

Now return to the measurement from 02:13.

Suppose it eventually reaches the cloud at 08:17.

Both timestamps matter.

One tells us when the event happened. The other tells us when the cloud received it.

If those are treated as the same thing, the system may end up with all the data and still give a misleading picture of reality. A temperature spike at 02:13 appearing on a chart at 08:17 is not lost data, but it is data with the wrong context.

The problem becomes particularly visible after a long outage, when thousands of old measurements arrive in a short period.

That is the subject of Your IoT Data Is Lying to You.

MQTT solves part of the journey

MQTT is often exactly the right protocol for IoT.

QoS 1 and QoS 2 give useful guarantees between MQTT participants, but those guarantees stop somewhere.

A broker can receive a message successfully and a later service can still fail to deliver the event to an API or cloud application.

MQTT has not failed. It has completed its part.

That distinction matters in architectures such as:

Device → MQTT → service → API → cloud application

The event can be reliably delivered through MQTT without the complete journey being reliable.

We cover that boundary in MQTT QoS Doesn't Guarantee End-to-End Delivery, MQTT Says Delivered. But Was It? and MQTT Got the Message There. What Happens Next?

MQTT does not need replacing. You just need to know where its responsibility ends.

The gap before the cloud

Cloud delivery systems can retry, replay, rate-limit and protect destinations.

But only after they have received the event.

If an event disappears locally, the cloud has nothing to recover.

For IoT, that means reliability often has to start before normal cloud delivery does. A device may be offline. A local process may restart. An event may simply never leave the site.

That is the gap described in The Reliability Gap Before the Webhook.

Moving delivery out of the application

One way to simplify the local side is to let the application hand off custody to a durable local component.

Once the event has been persisted, the application can continue with its own work while something else owns reconnect, retries, lost ACKs and backlog recovery.

Queuey Edge uses this model.

A successful PublishAsync means the event has been persisted locally and custody has moved out of the application.

Application → Queuey Edge → Queuey Cloud → Destination

Not every IoT system needs this. If losing an occasional update is acceptable, or the newest state always replaces the previous one, the additional reliability may not be worth the complexity.

But when the event itself matters, knowing exactly where custody sits makes the architecture much easier to reason about.

Publish Once: Why Your Application Shouldn't Own Retry Logic looks at the same problem from the application side.

Reliability before intelligence

There is a lot happening at the IoT edge. Devices are becoming more capable, more processing is moving locally, and AI will increasingly run close to where data is produced.

That is all useful.

But before making the edge smarter, there is a more basic requirement:

When something important happens, make sure the system remembers it.