An IoT application can be working perfectly while its internet connection is not.
That sounds obvious, but a surprising amount of application logic is still written as if cloud connectivity were part of the normal execution path. A measurement is produced, the application calls an API, and success or failure of that API call becomes part of the application's own state.
That works until the connection disappears.
Consider a controller in a factory. It keeps running, reading sensors and making local decisions even if the external connection is unavailable for forty minutes. From the factory's point of view, the system is still operating. From the application's point of view, however, every event it wants to send to the cloud is now a failed network request.
If those events matter, the application has to do something with them.
It can hold them in memory, which works until the process restarts. It can write them to a local database, but then it needs to track what has and has not been sent. It can retry periodically, but retries need backoff and some way to avoid hammering the connection when it returns.
The cloud outage has gradually become application logic.
Treat connectivity as a variable
For systems running in factories, vehicles, ships, kiosks or remote installations, connectivity is rarely binary in the useful sense of “working” or “broken”.
It changes.
The network may be available but slow. DNS may fail briefly. A TLS connection may time out. The device may have connectivity to one service but not another. Mobile coverage may disappear and return repeatedly.
The application should normally be able to perform its local job without turning these network conditions into domain decisions.
If a temperature reading needs to be recorded, recording it should not depend on whether a cloud endpoint happens to respond at that exact moment.
The cleaner separation is:
- The application produces the event.
- The event is accepted locally in a durable way.
- Delivery happens independently when the next system is reachable.
This is store-and-forward in its simplest form. The difficult part is making the “store” and the “forward” reliable enough that the application can genuinely stop caring after the handoff.
Memory is not an offline strategy
Keeping unsent events in memory is tempting because it is easy.
For short interruptions it can work perfectly well.
But the guarantee it provides is very specific: the event survives until either connectivity returns or the process disappears.
If the machine restarts, the process crashes or the application is redeployed, the backlog goes with it.
That may be completely acceptable for replaceable state. A room-temperature sensor publishing every five seconds may not need every individual reading. The latest value could be enough.
It is very different if the event represents something that happened once: a machine fault, an alarm, a completed batch or a door opening.
For those events, offline usually implies durable local storage.
Local durability creates another system
Once events are persisted locally, somebody has to manage them.
You need to know which events are pending. You need to delete or archive events that have safely moved on. You need a strategy for storage limits. If a device stays offline for a week, the backlog may become much larger than expected.
Then connectivity returns.
Sending the entire backlog as quickly as possible may overwhelm the network or the receiving service, so draining needs some control. If the connection disappears halfway through, the system should continue from a sensible point next time.
The application may also restart while events are pending. Recovery then needs to be deterministic: the backlog before restart should still be the backlog afterwards.
None of this is unusual engineering. It is simply more than “retry when offline”.
A successful local handoff changes the application
The application gets simpler when it has somewhere local to hand responsibility to.
Suppose the contract is:
PublishAsync(event)
If that call returns only after the event is durably persisted, the application can stop treating internet connectivity as part of the operation.
The event happened. It was accepted locally. The application moves on.
A separate delivery layer can deal with whether the cloud is available now, in ten minutes or tomorrow.
Queuey Edge uses this type of contract: a successful publish means the event is durably accepted on the local machine and delivery mechanics move outside the application.
The important idea is broader than any particular product. A local success should mean enough that the application can safely forget the event.
Offline can last longer than expected
One practical mistake is designing the offline path for the outage you expect.
Maybe interruptions normally last five minutes, so the local queue is sized around that assumption.
Then a firewall configuration is changed on Friday afternoon and the system remains disconnected until Monday.
A useful offline design needs explicit answers to a few boring questions:
How much can be stored?
What happens when the limit is reached?
Does the producer receive a clear failure, or are new events silently discarded?
Can operations see how large the backlog is?
Does the system preserve the original event time?
How quickly does the backlog drain when connectivity returns?
These details are what turn offline support from a demo feature into reliable infrastructure.
The application should know less
It is reasonable for an application to know that an event could not be accepted locally. That is an immediate problem it may need to react to.
It is much less useful for the application to know that the internet is down, that the cloud returned 503, or that the next retry is scheduled in 47 seconds.
Those are delivery concerns.
For an IoT application, a useful goal is therefore not “always be online”.
It is to make being online largely irrelevant to the part of the application that produces important events.
For the mechanics of what happens to accumulated data during a longer outage, continue with What Happens to Your Telemetry When the Internet Disappears?