Protocol choice for a connected device looks like a technical preference and behaves like a product decision. It determines battery life, data cost, how the device behaves when the network is poor, and how much your platform team has to learn. HTTP is the comfortable default and it is frequently the wrong one.
01The overhead difference is not marginal
An HTTPS POST carries request headers, response headers and a TLS handshake if the connection is not already open. For a payload of a few dozen bytes - which is what most telemetry actually is - the overhead can exceed the data by an order of magnitude. Over cellular, you pay for every byte and every radio wake-up.
MQTT holds one long-lived connection and sends a publish with a header measured in single-digit bytes. On a device reporting every thirty seconds, that difference compounds into meaningfully different battery life and a data bill that differs by a factor rather than a percentage.
| HTTPS (new connection) | HTTPS (keep-alive) | MQTT | |
|---|---|---|---|
| Bytes on wire | ~4-6KB | ~500B | ~60B |
| Round trips | 3-4 (TLS) | 1 | 0 (already connected) |
| Radio wake time | Highest | Moderate | Lowest |
| Server can push | No, poll only | No | Yes, natively |
02Downlink is the part HTTP cannot do
Telemetry is only half the problem. Sooner or later you need to send something to the device - a configuration change, a command, an update trigger. With HTTP the device must poll, and the polling interval sets your worst-case command latency directly against your battery budget.
MQTT gives you a subscription, so the platform pushes when it has something and the device is otherwise silent. Any product with remote control, remote configuration or an emergency stop needs this. Building it on polling means choosing between a responsive device and one whose battery lasts.
03QoS levels, and why 1 is almost always right
QoS 0 is fire-and-forget: cheapest, and messages can be lost silently. QoS 1 guarantees delivery at least once, which means duplicates are possible. QoS 2 guarantees exactly once through a four-step handshake that costs meaningfully more on a constrained link.
In practice QoS 1 plus deduplication on the receiver is the right answer for nearly all telemetry. QoS 2 is rarely worth its cost, and the deduplication logic you need for QoS 1 is simple - a message id and a short-lived set of recently seen ids. QoS 0 is fine for high-frequency readings where a lost sample genuinely does not matter.
| Message | QoS | Reasoning |
|---|---|---|
| High-frequency sensor reading | 0 | Next reading arrives shortly anyway |
| Periodic status report | 1 | Loss creates gaps in history |
| Alarm or fault event | 1 | Must arrive; duplicates are harmless |
| Command to device | 1 | Must arrive; make the command idempotent |
| Billing-relevant meter reading | 1 + dedup | Correctness matters, QoS 2 rarely justified |
04Store and forward, and timestamps at the source
The device must buffer locally when the link is down and forward when it returns. Without that, every connectivity gap becomes a permanent hole in your data, and connectivity gaps are constant in the field.
Equally important: timestamp readings on the device at the moment of capture, not on the server at ingest. If you timestamp at ingest, a device that buffers for six hours produces six hours of readings that all appear to have happened at once when it reconnects, which corrupts every downstream analysis.
05When HTTP is genuinely the better choice
Mains-powered devices on wifi with an existing HTTP stack, reporting infrequently, do not benefit much from MQTT and do pay for a broker. Devices behind restrictive corporate firewalls sometimes cannot get MQTT out at all. And if the payload is genuinely large - an image, a log bundle - HTTP is the better transport regardless.
A common and sensible hybrid is MQTT for control and small telemetry, HTTPS for bulk uploads. That keeps the persistent connection cheap while not forcing large transfers through a protocol that was not designed for them.
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer