Blog - MQTT QoS and backpressure — when QoS 2 hurts

In Modbus → MQTT integrations there is a common instinct: “set QoS 2, it’ll be safest.” Under telemetry bursts, QoS 2 can increase latency and deliver stale data.

Queue model

Assume a broker or edge gateway has a finite queue of capacity $N$. With arrival rate $\lambda$ msg/s and service rate $\mu$ msg/s, utilization is:

$$\rho = \frac{\lambda}{\mu}$$

As $\rho \to 1$, the mean queue length (M/M/1) grows as:

$$L = \frac{\rho}{1 - \rho}$$

QoS 2 adds handshake round-trips (PUBREC / PUBREL / PUBCOMP), so effective $\mu$ drops — $\rho$ rises faster than with QoS 0/1.

Decision flow

Practical rule

1. High-frequency telemetry — QoS 0 + coalescing (latest value wins).
2. Alarms / commands — QoS 1 (at least once) with an idempotent consumer.
3. QoS 2 — only when exactly-once is a business requirement and volume is low.

Latency budget

If you accept max delay $T$ seconds during bursts, with mean message size $s$ bytes and bandwidth $B$ B/s:

$$N_{\max} \approx \frac{B \cdot T}{s}$$

Exceeding $N_{\max}$ without drop/coalesce means “reliable” QoS 2 still delivers stale samples.

Takeaway

Reliability in IoT is not max QoS — it is an explicit contract: which data must always arrive, and which only needs “latest wins.”