Why the MQTT protocol drops on unstable connectivity in an application
A connectivity drop in a mobile app rarely looks like “the network is gone.” It’s a switch from Wi-Fi to LTE, stepping out of an elevator, the phone going to sleep — and the broker session dies quietly, without a single error in the logs.
To the user, it looks like “the app is lying”: the sensor reading has frozen, while the connection indicator is green.
The mobile carrier drops idle connections after a few minutes, while the MQTT protocol notices this only by the activity timeout.
If the interval is set longer than the carrier’s window, the connection becomes half-open: the client is sure it is online, the broker no longer sees it, and messages go nowhere.
Loss of sensor messages is usually unnoticeable. Telemetry without delivery confirmation disappears along with the session — a gap on the chart that neither the app nor the server reports.
The opposite extreme is duplicates after reconnection: the client resends unacknowledged packets, and aggregates count the same reading twice.
If retries happen at a short interval, the radio module does not have time to sleep, and the app’s background operation drains the battery in a matter of hours.
All four failures are the consequence of one thing: the session, timers, and local buffer are not coordinated with one another. Let’s break down how this is closed.
What event-driven message delivery gives a mobile app
Event-driven message delivery over MQTT changes not the speed but the class of tasks the app handles reliably.
Instead of constant polling, the client receives a message at the moment of the event: the delivered share rises from 92–94% to 99.8%, while duplicates and ordering are handled at the acknowledgment level rather than by catch-up polling.
The server-side message queue holds undelivered messages for the device while it is offline and delivers them when it returns to the network — with session preservation.
Recovery time after a drop is reduced to a few seconds: reconnection uses increasing backoff, so a network outage does not turn into a request storm.
The app’s battery consumption drops severalfold. Constant polling keeps the radio and background wakeups active even without events; with the event-driven model, the client sleeps, and the connection is maintained by infrequent service exchanges. Delivery no longer depends on how aggressively the system saves power on a particular device.
The load on the backend changes differently: high-frequency polling that set the peak flow disappears. The broker distributes only what actually changed — traffic volume per device drops, and scaling is limited by the number of connections rather than requests.
A whole class of failures goes away: “stuck” statuses, lost notifications, and desynchronization between the screen and the server state.
MQTT protocol: connection modes and their limitations
The connection mode is chosen not out of habit but based on how the device is powered and how quickly it must receive a command. This determines whether the server holds client state, how much traffic is wasted, and what happens to commands after a connection drop. Below are four schemes that teams actually choose between when implementing MQTT in a mobile app.
| Option | When it fits | Limitations |
|---|---|---|
| Persistent session | Device is almost always online, instant command response is needed | Holds state on the server, higher battery consumption; after a long offline period, a message queue accumulates |
| Short connections | Scheduled telemetry, infrequent commands, priority is battery saving | Command waits for the next connectivity window; instant delivery is impossible by definition |
| Buffer with delivery confirmation | Unstable channel, guaranteed command receipt is needed | Duplicates are possible on resend — the handler on the device must be idempotent |
| Bridge between local and cloud server | Part of the fleet is in a closed perimeter, part in the cloud | A second segment appears, separate bridge state monitoring, latency adds up |
In practice, the schemes are combined: a persistent session is left for devices with external power, short connections for wearables, a buffer with confirmation for lossy channels.
A bridge is added when part of the fleet must remain in a closed perimeter while control and analytics live in the cloud.
Implementation stages: from audit to handover to operations
We move to work in a fixed order — this is how MQTT is not implemented as a series of edits on a live product. Each implementation stage ends with a verifiable artifact: a diagram, a configuration file, or a test-run report. The customer accepts the result based on a document, not on the feeling that “it seems to work.”
- Audit of current exchange. We gather how the app communicates with devices today: message list, frequency, criticality of each, and where data is lost during network switching.
- Data flow diagram. We fix the topic tree, publish direction, delivery level for each stream, and rules for storing the last value.
- Permissions and buffers. Separate credentials per device, access by topic mask, queue size, and behavior when it overflows — so a traffic burst does not drop the connection.
- Testing under connection drops. We run network switching, app backgrounding, long loss of connectivity: we check subscription recovery, message ordering, duplicates, and client loss notification.
- Load and resources. Number of simultaneous connections, traffic volume, impact of a persistent background channel on battery consumption.
- Documentation. Topic conventions, procedure for adding new streams, and troubleshooting procedure for typical failures.
- Handover to operations. Metrics, alerts on connection drops, support instructions, and the support period.
The order is not accidental: without an audit, the stream diagram remains speculative, and drop testing without configured buffers shows false losses.
What we hand over to the customer: diagrams, access policies, documentation
At the end of the project, a set of artifacts remains that lets the app be developed without the original authors: without them, any enhancement turns into reverse engineering.
Below is exactly what is recorded in the documentation and handed over to your team along with the source code.
- Integration diagrams: map of app connections to the broker, list of topics with publish and subscribe direction, device and role tree, connection points for external services and state storage.
- Access policies: a “device role — allowed topics — delivery guarantee level” matrix, rules for issuing and revoking credentials, key lifetime, and procedure for blocking a compromised device.
- Connection resilience settings: keepalive intervals, buffer sizes, retry counts and timeouts, queue behavior on disconnect, and rules for restoring retained sessions after network loss.
- Exchange documentation: payload formats with examples, message versioning rules, field mapping table, and scheme for handling commands and acknowledgments on the app side.
- Maintenance regulations: frequency of certificate and key rotation, cleanup of stuck sessions, alert thresholds for delivery delays and the share of lost messages, and incident investigation procedure.
- Team instructions: step-by-step scenarios “connect a new device,” “add a new topic,” “roll back configuration to the previous one,” and diagnostics of typical connection failures without access to the backend.
- Acceptance checklist: a set of checks for network loss, network switching, long disconnection, peak load, and recovery after failure — with the expected behavior indicated in each case.
The set is stored in the same repository as the code and updated together with it — so the documentation does not diverge from the actual configuration.
Practice: sensor telemetry without losses and extra connections
A fleet of several hundred devices delivered sensor telemetry using short polls: the app raised a connection for each measurement and immediately closed it.
In the field, the scheme fell apart — when switching between Wi-Fi and cellular, entire series of measurements were lost, and the log showed dozens of reconnections per shift. We studied the profile according to the OASIS MQTT specification and rewrote the transport.
What we changed
The device maintains one long-lived session: a persistent session, keepalive with headroom for an unstable channel, and delivery with server-side acknowledgment.
Measurements that did not go out to the network accumulate in a local queue and catch up with the broker after connectivity is restored, while the last sensor state is published as retained — a new connection immediately receives current values.
High-frequency and infrequent topics were separated into different levels: the former are sent in batches once per interval, the latter by event.
Metrics before and after
- Share of delivered measurements per shift: 91% → 99.6%.
- Reconnections per device: 40–60 → 3–5.
- Traffic volume per device per day: 4.5 times less.
- Series loss when returning from background: reproduced regularly → not reproduced.
Background mode was fixed separately: the system shuts down the socket when going to the background and does not allow keeping it indefinitely.
An on-disk queue plus session resumption on a system event provided delivery stability without constantly waking the radio — the device battery lasts noticeably longer, and the dispatcher sees a continuous series rather than a broken line.
What to do if the app already has its own message exchange?
Your own message exchange does not necessarily have to be thrown away entirely: while it keeps production running, a full replacement in one release means stopping the product for an indefinite period.
In practice, one of three coexistence schemes is chosen, and the decision depends on how many streams are critical to delivery latency and how deeply the previous loop is embedded in the app logic.
Compatibility with legacy services is closed by a bridge: an adapter connects the MQTT broker and the previous transport, laying out the same events into both loops.
Here, a unified topic model and an end-to-end message identifier are important — without them, duplicates and lost delivery acknowledgments appear at the junction.
The bridge is raised on the server side: brokers of EMQX level have ready-made forwarding rules, so the adapter is not written from scratch.
| Option | When it fits | Limitations |
|---|---|---|
| Parallel loop | New features are already on MQTT, the old one serves current clients | Two transports in support, divergence of data models |
| Phased migration by stream | Streams are loosely coupled, metrics exist for each | Longer timelines, a bridge is needed during the transition |
| Full replacement | The previous exchange is simple, clients can be updated all at once | High rollback risk, long downtime window |
The phased transition is carried out by stream: first telemetry and background tasks, where latency is not critical, then control commands and critical notifications.
Each stream is migrated behind a configuration flag so traffic can be returned to the old exchange with a single switch — this enables rollback without releasing a new build.
The decision to remove the bridge is made based on metrics: share of lost messages, delivery time, and number of discrepancies between the loops per day.
Technical doubts before implementation: addressing them point by point
Before implementing MQTT, the same questions almost always come up: will commands be lost during a connection drop, how to distinguish a retry from a new operation, who gets permissions during mass device onboarding. Below are answers that usually resolve these doubts before work starts.
What happens to messages if a device goes offline?
Undelivered packets remain in the session queue on the broker side, and the client picks them up upon reconnecting with the same identifier. The queue lifetime is set separately — it determines how long a device can be absent without losing commands.
How to distinguish a retry from a new command?
Confirmed delivery allows a retry, so a retry is not considered a failure. Each command has an operation identifier, and the handler on the device is idempotent: a repeated arrival does not change the state a second time.
Are a login and password enough for mass onboarding?
No. We issue a separate certificate for each device and restrict access to its own read and write topics — the device will not see other branches. Revoking one client does not affect the others and leaves a trace in the connection log.
How to make sure the solution will withstand fleet growth?
We run a load profile at the target number of connections and look at the share of delivered messages, reconnection time, and broker memory growth.
Connection drops are tested deliberately: node failure, network loss, simultaneous return of hundreds of devices — recovery must fit within the specified threshold.
Let’s discuss the task: what is needed for an estimate and work plan
To come back with an estimate and plan, a small set of inputs is enough for us.
A complete requirements tome is not needed — it is more important to understand the class of devices, the nature of the traffic, and how the app behaves during a connection drop and when switching between networks.
Then the review proceeds step by step: we look at the current client and broker, topic scheme, access rights, behavior during session recovery, and volumes of stored messages.
As a result, you receive a work plan with stages, delivery scope, and support terms — indicating what we do and what remains on your team’s side.
- What the devices are and how often they publish telemetry: periodic report, event stream, or commands for execution.
- Current client and broker stack, if they already exist, and platform limitations for which the app is being built.
- Communication scenarios: confirmed delivery, guarantee levels, offline queue, resubscription after a disconnect.
- Access requirements: device authentication, topic-level permission separation, channel encryption.
- Operating mode: expected number of simultaneous connections, peak loads, target recovery time.
- What already exists in terms of documentation, diagrams, and automated tests — so as not to rewrite what works.
Describe the task in free form: a couple of paragraphs about the product and devices already gives us a basis for review. We will come back with an estimate, a stage plan, and a post-launch support proposal — with checkpoints and rollback procedure.