Sensors Edge Hub Logo
MQTT QoS 1: Delivery, PUBACKs, and Duplicate Risk

MQTT QoS 1: Delivery, PUBACKs, and Duplicate Risk

MQTT QoS 1 answers a narrow reliability question: should a sender retry when it does not receive the matching acknowledgment? At this level, the sender retains a local copy of the message while waiting for PUBACK. If that acknowledgment does not arrive within a reasonable time, the sender retransmits. The result is at-least-once delivery, with duplicate delivery still possible (HiveMQ).

TL;DR: MQTT QoS 1 provides at-least-once delivery. The sender keeps a local copy until it receives the matching PUBACK and may retransmit while waiting. That retransmission can deliver the same message more than once.

What Does MQTT QoS 1 Mean?

QoS 1 means at least once. It does not mean exactly once. The sender keeps the message locally while it waits for the corresponding PUBACK (HiveMQ).

QoS 1 describes acknowledgment-based delivery behavior. It does not establish a latency figure, bandwidth cost, broker capacity, or suitable industrial use case. Those conclusions need evidence about the broker, clients, network, and workload.

Why Does the Sender Keep a Local Copy?

The local copy gives the sender something to retransmit if the matching PUBACK does not arrive within a reasonable time (HiveMQ). Retrying supports at-least-once delivery, but it can also produce another delivery.

Why Can QoS 1 Produce Duplicate Delivery?

Duplicate delivery is possible because QoS 1 permits retransmission while the sender waits for PUBACK. The protocol-level promise is therefore at least once, not once and only once (HiveMQ).

For an industrial design review, this leaves a practical question rather than a universal rule: what would happen if the same message were delivered again? The answer depends on the application. The QoS label alone does not settle it.

What QoS 1 Does Not Establish

The source supports only the QoS 1 behavior described here. It does not establish the mechanics of QoS 0 or QoS 2, session persistence, retained messages, Last Will and Testament, Sparkplug B, cellular keepalive settings, or edge buffering. Nor does it provide general latency, throughput, traffic, or cost figures.

Frequently Asked Questions

What delivery behavior does MQTT QoS 1 provide?

MQTT QoS 1 provides at-least-once delivery. The sender retains a local copy while waiting for the matching PUBACK and can retransmit the message if that acknowledgment does not arrive (HiveMQ).

Why can MQTT QoS 1 deliver a duplicate?

Retransmission can produce a duplicate delivery. That possibility is part of the difference between at-least-once and exactly-once delivery.

Does PUBACK mean a message can appear only once?

No. PUBACK participates in the QoS 1 exchange, but the sender may retransmit while it is waiting for the matching acknowledgment. QoS 1 therefore retains duplicate risk.

Conclusion

MQTT QoS 1 provides at-least-once delivery. The sender retains a local copy, waits for PUBACK, and retransmits when the matching acknowledgment does not arrive within a reasonable time. That same mechanism can produce duplicates. Performance and deployment choices remain separate questions requiring separate evidence.

What delivery behavior does MQTT QoS 1 provide?
MQTT QoS 1 provides at-least-once delivery. The sender keeps a local copy while it waits for the matching PUBACK and may retransmit the message if that acknowledgment does not arrive.
Why can MQTT QoS 1 deliver a duplicate?
A retransmission can produce a duplicate delivery. QoS 1 therefore means that the message is delivered at least once, not that it is delivered exactly once.
Does a PUBACK remove duplicate risk at QoS 1?
No. PUBACK is part of the at-least-once exchange, but retransmission while waiting for the matching acknowledgment is also why duplicate delivery remains possible.