MQTT QoS Levels Animation

Interactive Comparison of QoS 0, 1, and 2 Message Delivery

In 60 Seconds

MQTT provides three Quality of Service (QoS) levels: QoS 0 (at most once, fire-and-forget), QoS 1 (at least once, with PUBACK acknowledgment but possible duplicates), and QoS 2 (exactly once, using a four-step handshake). Higher QoS levels increase reliability but add latency and network overhead.

MQTT Quality of Service Comparison

This interactive animation demonstrates the three MQTT QoS (Quality of Service) levels side-by-side. Watch how each level handles message delivery differently, from fire-and-forget to exactly-once delivery.

Animation Overview

This animation shows the three MQTT QoS levels:

• QoS 0 (At-most-once): Fire-and-forget, no acknowledgment
• QoS 1 (At-least-once): PUBLISH followed by PUBACK acknowledgment
• QoS 2 (Exactly-once): Four-way handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP)

How to Use This Animation

1. Click “Play All” to see all three QoS levels animate simultaneously
2. Use “Step Through” to advance one message at a time
3. Click “Simulate Loss” to see how each QoS handles network failures
4. Watch the packet counters to understand delivery guarantees

QoS Level Comparison Table

Feature	QoS 0	QoS 1	QoS 2
Name	At-most-once	At-least-once	Exactly-once
Guarantee	Best effort	Message delivered at least once	Message delivered exactly once
Packets	PUBLISH only	PUBLISH, PUBACK	PUBLISH, PUBREC, PUBREL, PUBCOMP
Network Overhead	Lowest (1 packet)	Low (2 packets)	Highest (4 packets)
Latency	Lowest	Low	Highest
Duplicates Possible?	No (but loss possible)	Yes (on retry)	No
Use Case	Sensor telemetry, frequent updates	Commands, alerts	Financial transactions, billing
Storage Required	None	Message until PUBACK	Message + state until PUBCOMP

Message Flow Details

QoS 0: Fire-and-Forget

Publisher                    Broker
    |                          |
    |-------- PUBLISH -------->|
    |                          |
    (done - no confirmation)

Characteristics:

• Fastest, lowest overhead
• No guarantee of delivery
• Used for non-critical data where occasional loss is acceptable
• Ideal for high-frequency sensor readings

QoS 1: Acknowledged Delivery

Publisher                    Broker
    |                          |
    |-------- PUBLISH -------->|
    |                          | (stores message)
    |<-------- PUBACK ---------|
    |                          |
    (delete message from queue)

Characteristics:

• Publisher retries until PUBACK received
• May result in duplicate messages if PUBACK is lost
• Subscriber should handle duplicates (idempotent operations)
• Good balance of reliability and performance

QoS 2: Exactly-Once Delivery

Publisher                    Broker
    |                          |
    |-------- PUBLISH -------->|
    |                          | (stores message, state = RECEIVED)
    |<-------- PUBREC ---------|
    |                          |
    |-------- PUBREL --------->|
    |                          | (delivers to subscribers)
    |<-------- PUBCOMP --------|
    |                          |
    (transaction complete)

Characteristics:

• Most complex, highest overhead
• Guarantees exactly-once delivery (no duplicates, no loss)
• Uses packet identifiers and state tracking
• Required for critical transactions (billing, commands)

When to Use Each QoS Level

Decision Guide

Choose QoS 0 when:

• Data is sent frequently (temperature every second)
• Missing a value is not critical
• Network is reliable
• Battery life is important

Choose QoS 1 when:

• Messages must be delivered
• Duplicates can be handled (idempotent)
• Commands or alerts that need confirmation
• Most common choice for IoT

Choose QoS 2 when:

• Duplicates would cause problems
• Financial or billing data
• Critical state changes
• Compliance requirements

Real-World Examples

Application	Recommended QoS	Reason
Temperature sensor (1/sec)	QoS 0	High frequency, loss acceptable
Smoke detector alert	QoS 1	Must be delivered, retry OK
Door lock command	QoS 1	Critical, idempotent operation
Payment transaction	QoS 2	No duplicates allowed
Energy meter reading	QoS 2	Billing accuracy required
Location updates	QoS 0	Frequent, superseded by next update
Firmware update trigger	QoS 1	Must arrive, retry safe

What’s Next

• MQTT Pub/Sub Animation - See the publish-subscribe pattern in action
• MQTT Fundamentals - Deep dive into MQTT protocol
• MQTT Session Management - Persistent sessions and retained messages
• CoAP vs MQTT - Compare with CoAP’s confirmable messages
• Simulations Hub - More interactive visualizations

---

Animation Technical Notes

This animation is implemented in approximately 450 lines of Observable JavaScript. Key features:

1. Parallel timelines: Three independent QoS flows shown side-by-side
2. Step-through mode: Manual advancement for teaching
3. Loss simulation: Toggle to demonstrate reliability differences
4. Statistics tracking: Real-time counters for sent/received/lost
5. D3 transitions: Smooth packet animations with easing
6. IEEE color palette: Consistent visual design

The animation demonstrates the fundamental trade-off between reliability and overhead in MQTT QoS levels.

Related Interactive Tools

Explore More MQTT Tools

• MQTT Pub/Sub Animation - Basic publish-subscribe flow
• MQTT QoS Levels - Compare QoS 0, 1, and 2
• MQTT Last Will - Client disconnect detection
• MQTT Retained Messages - Message persistence
• MQTT Clustering - Broker scaling
• QoS Playground - Interactive QoS testing
• MQTT Topic Designer - Topic hierarchy design

Common Pitfalls

Pitfall 1: Using QoS 2 for Everything “Just to Be Safe” Students often default to QoS 2 thinking it’s always the best choice. This dramatically increases latency (4 packets vs 1), consumes more bandwidth, and drains device batteries faster. For a temperature sensor sending readings every second, QoS 2 adds unnecessary overhead since the next reading supersedes any lost message.

Pitfall 2: Assuming QoS 1 Means Exactly-Once Delivery QoS 1 guarantees at-least-once delivery, NOT exactly-once. If the PUBACK is lost, the sender retransmits, causing the subscriber to receive duplicates. Your application must be idempotent (handle duplicates gracefully) or use QoS 2 when duplicates are unacceptable.

Pitfall 3: Ignoring QoS on Subscribe vs Publish The effective QoS is the minimum of the publisher’s QoS and subscriber’s requested QoS. Publishing at QoS 2 while the subscriber subscribed at QoS 0 results in QoS 0 delivery to that subscriber. Both sides must agree for guaranteed delivery.

Pitfall 4: Forgetting Packet ID Reuse Constraints QoS 1 and 2 use 16-bit packet IDs that must be unique per client-broker pair. Rapid publishing without waiting for acknowledgments can exhaust the ID space or cause ID collisions, leading to message misrouting or duplicate detection failures.

Key Takeaways

• QoS levels trade reliability for overhead: QoS 0 uses one packet (fire-and-forget), QoS 1 uses two packets (acknowledged), and QoS 2 uses four packets (exactly-once) - choose based on your delivery guarantee needs.
• QoS 1 is the most common choice for IoT: It ensures at-least-once delivery with reasonable overhead, making it ideal for commands and alerts where duplicates can be handled.
• QoS 2 prevents duplicates at the cost of latency: The four-way handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP) guarantees exactly-once delivery, essential for financial transactions and billing data.
• QoS 0 suits high-frequency sensor data: When readings come every second and missing one value is acceptable, fire-and-forget delivery saves battery and bandwidth.