Quality of Service

Quality of Service (QoS) levels define message delivery guarantees in MQTT, governing the interaction between the broker and connected clients. This feature is pivotal for building reliable communication systems in IoT environments.

QoS helps tackle these common challenges:

• Network reliability — QoS 1 and QoS 2 ensure messages are delivered even when TCP drops packets under poor conditions.
• System crashes — if a publisher or subscriber crashes mid-transmission, QoS prevents message loss.
• Preventing duplicates — QoS 2 guarantees the message is delivered exactly once.
• Avoiding subscriber overload — with QoS 1 and QoS 2, the publisher pauses sending if the client is not acknowledging previous messages.
• Persisting messages — QoS 1 and QoS 2 messages can be queued for offline clients and delivered upon reconnection.

MQTT defines three levels:

1. QoS 0 — At most once (default). Speed over reliability; suitable for non-critical data.
2. QoS 1 — At least once. Important data where occasional duplicates are manageable.
3. QoS 2 — Exactly once. Critical data where neither loss nor duplication is tolerable.

A message is delivered at most once — no duplicates are possible, but delivery is not guaranteed.

Requires one message:

1. Sender sends PUBLISH packet.

After sending, the message is removed from the queue. This mode is sometimes called “fire and forget” because no acknowledgment is expected.

QoS 0 has the fastest performance and minimal network overhead. It has the lowest reliability — messages can be lost due to network instability or unexpected disconnections. It is not suitable for critical data where every message must be received.

Messages are delivered at least once, ensuring the receiver gets the message, but duplicates are possible.

Requires two messages:

1. Sender sends PUBLISH packet.
2. Receiver responds with PUBACK packet.

Duplicates can occur in two scenarios:

1. The PUBLISH is lost in transit — the sender retransmits until it receives a PUBACK.
2. The PUBACK is lost — the sender retransmits, causing the receiver to get the message twice.

Messages are delivered exactly once — no duplicates and no loss.

Requires four messages:

1. Sender sends PUBLISH packet.
2. Receiver responds with PUBREC packet.
3. Sender sends PUBREL packet (includes packet ID to prevent duplicate processing).
4. Receiver sends PUBCOMP packet.

Only after receiving PUBCOMP does the sender remove the message or reuse the packet ID. The four-step handshake provides the highest guarantee but has the slowest performance and highest network overhead.

Suitable when speed matters more than reliability, or when occasional loss is acceptable:

• Environmental sensor data — periodic greenhouse temperature updates; if a reading is lost, the next one corrects the state.
• Smart lighting status updates — a missed message is corrected by the next update.

Suitable when data loss is unacceptable but duplicates can be handled:

• Vehicle telemetry — location and fuel level sent to a fleet management system. If a network disconnection occurs or an acknowledgment is delayed, the client resends the data, which may result in duplicates at the fleet system. Occasional duplicates are acceptable, but data must arrive.
• Home security alerts — motion or door sensors notifying a smartphone app. If the broker fails to send an acknowledgment due to network latency or interruptions, the security system retransmits the alert, potentially sending multiple notifications for the same event. The alert must arrive even if it means a duplicate notification.

Best for critical applications where both duplication and loss are unacceptable:

• Financial transactions — payment details between terminals and a server; each transaction must be processed exactly once.
• Industrial automation commands — precise commands to machinery that must execute exactly once to avoid errors.

	Performance	Delivery guaranteed	Duplicates	Packets
QoS 0 — At most once	Fastest	No	Impossible	PUBLISH
QoS 1 — At least once	Normal	Yes	Possible	PUBLISH, PUBACK
QoS 2 — Exactly once	Slowest	Yes	Impossible	PUBLISH, PUBREC, PUBREL, PUBCOMP

In MQTT, the publisher and subscriber must use the same Quality of Service level to communicate correctly. However, the QoS of a published message and the QoS of a subscribing client may differ. In this case, the lowest QoS is used for delivery, regardless of which side has the lower value.

Example: Client A publishes with QoS 1; Client B subscribes to the same topic with QoS 2. The message is delivered with QoS 1.

QoS interacts with session type:

• Clean session (clean session = true) — regardless of QoS, the broker stores no state for the client. All queues and unacknowledged messages are lost on disconnect.
• Persistent session (clean session = false) with QoS 1 or QoS 2 — the broker queues messages for disconnected clients. Messages are delivered in the order they were published, even after the client reconnects.

Upon reconnection, clients should be prepared to handle potentially large message bursts. Each message must be acknowledged by the client to be removed from the queue. Clients should also handle duplicates that may result from redelivery.