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.