Direct answer

Use the lowest MQTT QoS that satisfies the failure model of a single network hop, then design the application as if duplicates, delays, reordering, and data loss can still happen. QoS 0 fits data that is quickly replaced by a newer sample. QoS 1 is the practical default when losing an individual publication matters and duplicate processing is safe. QoS 2 is justified only when its two-phase exchange solves a measured hop-level problem; it does not create exactly-once business processing.

Scope and non-scope

This guide covers delivery between one MQTT client and one broker, plus the consequences of forwarding a publication to subscribers. It does not prove that a sensor sampled correctly, a subscriber committed a transaction, or an actuator completed a command. Those outcomes require application acknowledgements, durable state, and reconciliation beyond MQTT QoS.

QoS is selected independently on each delivery leg. A publisher can send at QoS 1 while a subscriber receives at QoS 0 because delivery uses the lower of the publication QoS and the subscription’s maximum QoS. Retained messages, persistent sessions, message expiry, and broker queue policy also affect what a reconnecting subscriber receives.

Decision criteria

Start with the consequence of missing one message. Periodic temperature telemetry sampled frequently often tolerates a lost sample because the next value supersedes it. A transition such as “pump entered fault” may need QoS 1, durable consumption, and an event identifier because a replacement reading does not preserve the transition. A safety workflow may need an application transaction and explicit outcome confirmation; choosing QoS 2 alone is not enough.

Then evaluate duplicate cost. QoS 1 deliberately permits redelivery when an acknowledgement is lost. Put a stable event or command identifier in the payload and make the consumer record completion against it. Do not use MQTT packet identifiers as business keys: they are scoped to a network session and may be reused.

Finally account for the link and recovery path. QoS 1 adds acknowledgements and keeps publications inflight until acknowledged. QoS 2 adds PUBREC, PUBREL, and PUBCOMP state. On a lossy cellular network, that state increases airtime and can lengthen recovery. Measure inflight windows, retransmission behavior, queue limits, and message expiry with the actual clients and broker.

Workload Starting point Additional control
High-rate replaceable telemetry QoS 0 Sequence numbers and freshness limits
Discrete event that must reach the platform QoS 1 Idempotent event processing
Device command QoS 1 Command ID, expiry, acknowledgement, outcome state
Relay with a strict hop-level duplicate constraint Evaluate QoS 2 Prove the exact benefit and state cost

Implementation steps

  1. Classify each message as replaceable state, durable event, command, acknowledgement, or bulk transfer.
  2. Write the loss and duplication consequence before assigning QoS.
  3. Add event or command identifiers and an idempotency store where repeated side effects are unsafe.
  4. Set message expiry so stale queued telemetry and commands cannot execute after their useful window.
  5. Bound client and broker inflight messages, offline queues, and retry time.
  6. Test connection loss before and after every protocol acknowledgement, not only clean delivery.
  7. Observe publish acknowledgements, redeliveries, expired messages, queue age, and consumer completion separately.

Failure modes to test

A QoS 1 consumer that increments a counter on every delivery will overcount after redelivery. A device that executes a command before persisting its command ID can repeat the physical action after reboot. A persistent subscriber can reconnect to a large backlog and process obsolete commands unless messages expire. A publisher can receive PUBACK while the downstream business service is unavailable because broker acceptance is not application completion. QoS 2 can still duplicate an operation when data leaves MQTT and enters a database or another broker.

Test broker restart, client restart with and without durable session state, acknowledgement loss, exhausted inflight windows, queue overflow, and reconnect after message expiry. Record both wire delivery and the final business outcome.

Implementation checklist

  • Every message class has an explicit loss and duplication policy.
  • Consumers use stable application identifiers for idempotency.
  • Commands have expiry, acknowledgement, and outcome semantics.
  • Inflight and offline queues have documented limits.
  • Session expiry matches the product’s offline expectations.
  • Failure tests cover disconnects at each acknowledgement stage.
  • Metrics distinguish broker acceptance from business completion.

Primary sources

MQTT 5.0 sections 4.3 and 4.4 define QoS flows and delivery behavior. Sections 3.3, 3.8, and 4.1 describe publication, subscription maximum QoS, and session state. Use the OASIS MQTT 5.0 specification as the normative reference, then verify persistence and queue behavior in the selected broker and client documentation.