MQTT Quality of Service: Getting a Detection Event Out of a Flaky Store

Why MQTT for this traffic shape

Many stores, each publishing small, frequent detection events to one central dashboard, over connections that drop. A lightweight publish-subscribe protocol fits: its 2-byte fixed header against roughly a kilobyte of HTTP headers per message matters at that volume, and the broker handles the many-to-one fan-in without a bespoke endpoint per store. MQTT QoS for retail edge is about choosing how hard the protocol tries to deliver each of those events.

The three QoS levels

• QoS 0 — "at most once." Fire and forget, no acknowledgement. Fine for a high-frequency sensor reading where the next one is a second away. Wrong for a stockout alert you can't afford to drop.
• QoS 1 — "at least once." The broker retries until acknowledged. The event arrives, possibly more than once, so the consumer dedupes on an event ID — the same idempotency logic used elsewhere in the pipeline.
• QoS 2 — "exactly once." A four-step handshake guaranteeing single delivery. The safest and the slowest, and usually overkill for a detection event that's already idempotent downstream.

The recommendation for shelf alerts

QoS 1 plus downstream dedupe. You get delivery through a flaky connection without paying the QoS 2 handshake on every message. On our computer vision project only a small structured detection result leaves the store, and at-least-once delivery of that result with a dedupe key is the right balance of reliability and overhead.

Retained messages

The broker keeps the last message on a topic, so a dashboard or a reconnecting store gets the current state immediately instead of waiting for the next publish. Useful for "current shelf status per store" — set them deliberately, because a retained message on a high-churn topic can serve a stale state.

Last will and testament

The broker publishes a pre-set message if a store's connection drops unexpectedly, so "store 47 went offline" is itself an event, not silence.

Reconnect and backfill

A store that was offline reconnects and its queued events flow. QoS 1 plus persistent sessions makes that work — the backlog isn't lost, it just arrives late.

The dedupe key, concretely

Each detection event carries a store ID, a capture ID, a timestamp, a SKU, and a shelf position. The dedupe key is a hash of those fields. The consumer keeps a short-lived set of keys it has already processed — with a time-to-live longer than the maximum QoS-1 retry window — and drops any event whose key is already there. That turns at-least-once delivery into exactly-once processing without needing QoS 2.

Topic design

One topic per store — stores/47/detections — so the dashboard can subscribe to stores/+/detections for the whole estate or stores/47/# for a single store. Put the last-known shelf state on a separate retained topic like stores/47/status, so a dashboard loading fresh gets current state instantly instead of waiting for the next detection to arrive.

This is also how 150-plus stores publishing at once stays manageable: the dashboard opens one wildcard subscription and the broker fans everything in. The broker is the single connection point to scale, secure, and monitor — not 150-plus inbound endpoints, each with its own auth and its own failure mode.

Where this stops being right

• QoS 2 for events already idempotent downstream is wasted latency and broker load.
• Retained messages on a high-churn topic can serve a stale "current state" if not managed.
• Running your own broker is operational surface — a managed MQTT service removes it, the same trade as with any messaging infrastructure.

FAQ

Which QoS level for a stockout alert? QoS 1 — at-least-once — plus dedupe on an event ID downstream. QoS 0 can drop it; QoS 2 is overkill.

What happens when a store goes offline mid-shift? QoS 1 with persistent sessions queues its events; a last-will message fires so "store offline" is an event; on reconnect the backlog flows.

Do we need our own broker? You need the broker semantics. A managed MQTT service gives them without running the broker yourself.

Do events arrive in order? MQTT preserves order per topic, per publisher. If you need strict ordering across stores — you usually don't for shelf alerts — timestamp the events and sort them downstream rather than relying on the transport.

ISTRALLEN builds store-to-dashboard messaging on MQTT with at-least-once delivery and downstream dedupe; see AI for Retail.