MQTT QoS: Understanding The 3 Levels Of Service

---

CONTEXT

01 / 06

What Is MQTT QoS?

MQTT Quality of Service (QoS) is a delivery agreement between a message sender and the broker that defines how much effort both sides invest in ensuring a message arrives. It is the primary mechanism for controlling reliability versus performance in any MQTT-based IoT system.

Devices in IoT networks operate under unpredictable conditions — intermittent cellular coverage, congested Wi-Fi, and constrained battery life. MQTT was designed for these environments, and QoS is its core reliability control. The protocol offers exactly three levels, and every message is tagged with one of them. The level you choose directly impacts whether messages can be lost, duplicated, or delivered with absolute certainty.

QoS is negotiated independently for each publish operation. A publisher sets the QoS level on outbound messages, and a subscriber requests a QoS level when subscribing. The broker enforces the lower of the two, so a subscriber asking for QoS 1 receiving a QoS 2 publish will get QoS 1 delivery guarantees. This per-message granularity lets you mix reliability levels within a single application — sending sensor readings at QoS 0 while commanding actuators at QoS 1, for example.

---

FRAMEWORK

02 / 06

The 3 MQTT QoS Levels Explained

Each QoS level defines a specific message handshake between client and broker. Higher levels add more round-trip packets to eliminate delivery failures, but at a direct cost to throughput, latency, and device battery life.

---

COMPARISON

03 / 06

QoS Level Comparison

The following table maps each QoS level against the five dimensions that matter most when architecting an IoT messaging system: delivery guarantee, network overhead, latency, power consumption, and implementation complexity.

Dimension	QoS 0: At Most Once	QoS 1: At Least Once	QoS 2: Exactly Once
Delivery Guarantee	No guarantee — message may be lost	Guaranteed at least once — duplicates possible	Guaranteed exactly once — no loss, no duplicates
Packet Count	1 (PUBLISH only)	2 (PUBLISH + PUBACK)	4 (PUBLISH + PUBREC + PUBREL + PUBCOMP)
Relative Overhead	1x (baseline)	~2x	~4x
Latency	Lowest — single one-way trip	Medium — one round-trip for acknowledgment	Highest — two full round-trips
Power Consumption	Lowest	Medium	Highest — significant for battery-powered devices
Implementation Complexity	Simplest — send and forget	Requires duplicate handling (idempotent design)	Most complex — both sides must track transaction state
Recovery on Failure	None — message is gone	Automatic retransmission until PUBACK received	Automatic retransmission at any handshake stage

---

RECOMMENDATION

04 / 06

When to Use Each QoS Level

There is no single best QoS level — only the right level for your specific data type, device constraints, and network conditions. The three factors below determine the optimal choice.

---

BEST PRACTICES

05 / 06

Implementation and Best Practices

Implementing QoS in code is straightforward — set the qos parameter in your MQTT client’s publish call. The handshake logic is handled entirely by the library. Below is a practical reference using the Paho MQTT client for Python, followed by key practices for production systems.

Code Reference

import paho.mqtt.client as mqtt

client = mqtt.Client("publisher_id")
client.connect("broker.example.com", 1883)
client.loop_start()

QoS 0: high-frequency, non-critical telemetry
client.publish("iot/sensor/temperature", payload="23.5", qos=0)

QoS 1: command that must arrive (idempotent)
client.publish("iot/device/command", payload="TURN_ON", qos=1)

QoS 2: mission-critical transaction (exactly once)
client.publish("iot/system/payment", payload="TXN_12345", qos=2)

client.loop_stop()
client.disconnect()

Production Best Practices

1. Design for idempotency at QoS 1. Since duplicates are possible, every subscriber receiving QoS 1 messages must handle them safely. Use unique message IDs or timestamps to deduplicate, or ensure the operation is naturally idempotent (setting a state to ON twice has the same result as setting it once).
2. Set QoS per topic, not globally. Different data types within the same application have different reliability needs. Publish telemetry at QoS 0 and commands at QoS 1 on separate topics rather than applying one level to everything.
3. Reserve QoS 2 sparingly. The four-packet handshake quadruples network traffic and CPU load. Use it only where the cost of a duplicate genuinely exceeds the overhead. Most production IoT systems run almost entirely on QoS 0 and 1.
4. Use persistent sessions for QoS 1/2. Enable clean_session=False so the broker stores undelivered messages and pending acknowledgments across client reconnects. Without this, messages queued during an offline period are lost.
5. Monitor duplicate rates as a network health signal. A rising duplicate rate at QoS 1 indicates PUBACK packets are being lost — a sign of network degradation. Use this metric to trigger alerts before message delivery is affected.

---

ACTION

06 / 06

Next Steps

Applying the right QoS level is one of the highest-leverage architectural decisions in an IoT system — it affects reliability, latency, device battery life, and infrastructure costs simultaneously. The steps below give you a practical path from assessment to production.

1. Audit your current message types. List every topic in your system and classify each as non-critical telemetry, important command, or mission-critical transaction. Assign QoS 0, 1, or 2 accordingly.
2. Implement idempotent subscribers. For every topic at QoS 1, verify that duplicate messages cannot cause incorrect state. Add deduplication logic using message IDs or timestamps if the operation is not naturally idempotent.
3. Enable persistent sessions. Set clean_session=False on devices that receive QoS 1 or 2 messages so the broker buffers messages during offline periods and resumes delivery on reconnect.
4. Profile and optimize. Measure actual packet loss, duplicate rates, and battery impact on representative hardware. Adjust QoS levels down where the measured network reliability is higher than assumed.