Why QoS exists
Connected devices do not live on perfect networks. They sleep, they roam, and they drop packets. MQTT’s Quality of Service levels are a simple contract between publisher, broker, and subscriber that defines how hard the system should try to deliver a message.
QoS does not make data magically reliable. It gives you a clear set of behaviors so you can design around duplicates, losses, and ordering.
QoS 0: at most once
QoS 0 is “fire and forget.” The broker does not acknowledge delivery. It is the lowest overhead and best for high-volume telemetry where occasional loss is acceptable.
Think of temperature readings every second. If one is lost, the next one arrives soon. QoS 0 keeps traffic small and avoids storage pressure on the broker.
QoS 1: at least once
QoS 1 requires an acknowledgment. If the sender does not receive it, it will retry, which can cause duplicates. This is a good choice for commands or important state updates where loss is worse than duplicate processing.
When using QoS 1, build idempotent handlers. If a command arrives twice, the system should tolerate it without side effects.
QoS 2: exactly once
QoS 2 uses a two-phase handshake to ensure a message is delivered once and only once. It is the most reliable and also the most expensive in terms of latency and storage.
Use QoS 2 sparingly for messages that cannot be duplicated, such as billing events or high-stakes state transitions.
Choosing QoS by message type
Telemetry streams and frequent sensor data are perfect for QoS 0. Commands and user-triggered actions usually sit at QoS 1. Critical transactional events might justify QoS 2.
You can mix levels in the same system. What matters is that each topic has a purpose and a reliability contract.
QoS and retained messages
Retained messages store the last known value on the broker. A QoS level applies to the delivery of that retained message as well. Be mindful that high QoS retained messages can increase broker load.
For state topics, a retained QoS 1 message is a common sweet spot: new subscribers get reliable state without a heavy QoS 2 handshake.
Operational tips
Monitor retry rates and duplicate counts. If QoS 1 traffic creates too many duplicates, the issue is often network instability or poor client reconnection handling.
Document QoS per topic. Teams should not guess; they should know which topics are best-effort and which are critical.