MQTT's three quality-of-service levels are a frequent source of both over-engineering and dangerous assumptions. They do not guarantee delivery in any absolute sense - they change how the protocol handles delivery accounting and retries.
The Levels
- QoS 0 (at most once): the message is sent without acknowledgment. Fast and cheap; loss is possible. Fine for telemetry where a missed sample is acceptable.
- QoS 1 (at least once): the sender retries until the receiver acknowledges. Guarantees delivery - but duplicates can occur, so the receiver must be idempotent.
- QoS 2 (exactly once): a four-step handshake ensures a message is delivered exactly once. Highest overhead; needed only where duplicates are genuinely harmful.
Industrial Reality Check
Most industrial data is idempotent - the latest temperature reading supersedes the previous one, and a duplicate is harmless. QoS 1 with a well-designed payload (sequence number or timestamp) covers the vast majority of cases. QoS 2 is justified for commands with irreversible effects (start a batch, trip a device) where a duplicate execution is dangerous.
Beyond QoS: The Actual Reliability Stack
- Session persistence so the broker queues messages for disconnected subscribers.
- Retained messages for last-known-value state (for example, current mode of a machine) so new subscribers immediately see current state.
- Local buffering at the publisher: the edge gateway must queue data during link outages regardless of QoS - QoS does not survive a disconnected broker.
- Duplicate detection: use message IDs or timestamps in the payload so downstream systems can deduplicate and order.