MQTT QoS Delivery Workbench

Compare MQTT QoS 0, QoS 1, and QoS 2 delivery guarantees, overhead, retry behavior, and subscriber QoS caps.

Learner-ready MQTT QoS delivery workbench with scenario presets, step/play packet flow, loss and acknowledgement cases, effective subscriber QoS calculation, duplicate-risk guidance, source links, and local desktop/mobile visual verification.

Animation MQTT Delivery guarantees Intermediate

MQTT QoS Delivery Workbench

Choose a message scenario, step through the MQTT packet exchange, and see how QoS changes delivery confidence, overhead, duplicate risk, and subscriber delivery.

Selected guarantee At least once

Normal packet path 2 packets

Subscriber delivery QoS 1

Current risk Duplicate possible

1. Start with the message

Telemetry, alarms, commands, and billing records do not need the same delivery guarantee.

2. Watch the handshake

QoS 0 uses one PUBLISH, QoS 1 adds PUBACK, and QoS 2 uses PUBLISH, PUBREC, PUBREL, PUBCOMP.

3. Test the failure

Lost publishes, lost acknowledgements, and reconnects change what the protocol can promise.

4. Check the subscriber cap

The delivery to a subscriber is capped by the subscriber's requested maximum QoS.

1. PublishClient sends the application message to the broker.

2. ConfirmThe broker responds if the selected QoS requires it.

3. Retry or stateLoss can trigger retry or stored handshake state.

4. DeliverThe broker forwards to matching subscribers at effective QoS.

5. DecideThe learner weighs reliability, latency, battery, and app safety.

Animated packet path

Use Play or Step to trace the selected QoS exchange. The packet label, active stage, and diagnosis update together.

Active packet PUBLISH

Publisher MQTT client

->

Broker stores QoS state

Active packet PUBLISH

Broker applies subscription cap

->

Subscriber receives QoS 1

QoS 1 keeps state until PUBACK arrives.

QoS 1 publish requires acknowledgement. The publisher keeps the message until PUBACK arrives. If PUBACK is lost, a retry can create a duplicate delivery.

Protocol guarantee At least once

The sender retries until PUBACK is received, so duplicates are possible.

Overhead Moderate

Two packets are normal on the publisher-broker hop.

Subscriber QoS QoS 1

Publisher QoS 1 and subscriber maximum QoS 1 produce QoS 1 delivery.

Recommendation Good fit

This scenario needs confirmation, and duplicate-safe application handling is acceptable.

Scenario and controls

Change the message need, QoS level, failure case, and subscriber maximum QoS. The recommendation and packet path update immediately.

Message scenario Alarm alert

Publish QoS QoS 1

Failure case Lost PUBACK No packet loss PUBLISH lost Acknowledgement lost

Subscriber maximum QoS QoS 1 QoS 0 QoS 1 QoS 2

MQTT QoS is negotiated per hop. The publisher-broker path can use QoS 2 while a subscriber that requested QoS 0 still receives at QoS 0.

Learning Support

QoS 0 At most once

One PUBLISH packet. There is no acknowledgement, no retry, and no protocol evidence that the broker received the message.

QoS 1 At least once

PUBLISH plus PUBACK. Retransmission protects delivery but can duplicate the application message.

QoS 2 Exactly once at protocol hop

PUBLISH, PUBREC, PUBREL, and PUBCOMP coordinate state so that this MQTT hop does not deliver duplicates.

Technical Quick Reference

Packet Identifier QoS 1 and QoS 2 only

QoS 0 PUBLISH has no Packet Identifier. QoS 1 and QoS 2 use one so acknowledgements match in-flight messages.

Effective QoS min(publish, subscribe)

A broker forwards at no higher QoS than the subscriber requested, even when the original publish used a higher QoS.

Application safety Protocol is not the whole system

QoS confirms MQTT delivery semantics. It does not prove a lock moved, a valve closed, or a business action committed.

OASIS MQTT 5.0 specification OASIS MQTT 3.1.1 specification MQTT QoS level simulator

Practice Checks

Telemetry Frequent values

If a temperature value arrives every second and the next value replaces the previous one, QoS 0 is often enough.

Alert Must arrive

A smoke alarm event usually needs QoS 1 plus an idempotent alert handler so repeated delivery is harmless.

Billing No duplicates

Meter records and financial events may justify QoS 2, but the application database still needs transaction safety.