beginner 2 min answer Multiple choice

A metered NB-IoT fleet must not record a reading twice, because readings drive a customer's bill. The team proposes QoS 2 so the broker delivers each publish exactly once. Which choice fits better?

mqttqosidempotencynb-iotenergy
Pick one
Show the full answer Hide the answer

The deciding property

QoS 2 guarantees exactly-once delivery between one publisher and the broker, and nothing beyond it. The reading still travels from the broker to a consumer, through a queue, into a database, and any of those hops can be retried. Billing correctness is a property of the write at the end of that chain, so it has to be enforced there.

The mechanism costs real energy. QoS 1 is a two-packet exchange, PUBLISH then PUBACK. QoS 2 is four: PUBLISH, PUBREC, PUBREL, PUBCOMP. On NB-IoT, where a round trip is commonly hundreds of milliseconds to a few seconds and the radio is the dominant power draw, doubling the round trips roughly doubles the radio-on time for the delivery handshake. A device that lives for years on a battery pays that on every reading.

The choice

Publish at QoS 1 with a reading identifier the device generates and persists before the first send attempt, typically device id plus a monotonic counter. The ingest path makes the insert conditional on that identifier. A duplicate then collapses at the only place that matters, and it costs one unique index rather than two extra radio exchanges per reading.

Why the other options fail

  • QoS 2. It would be the right answer if the broker were the system of record and nothing came after it. Here it buys exactly-once on the first hop only, pays double the air time, and leaves the duplicate risk where it actually lives: retries behind the broker and reprocessing after a consumer crash.
  • QoS 0. Correct for a value that is superseded a minute later, such as a temperature sample. Wrong for a billing reading, because the loss is unbounded and invisible: nothing in the system knows a reading existed.
  • A server-side check on the timestamp. The timestamp comes from the device clock, which drifts, resets on power loss and is user-editable on many platforms. Two genuine readings can share a second, and one device can report the same second twice after a clock correction. Identity must be an identifier, not a measurement.

When this is the wrong answer

If the action cannot be made idempotent and cannot be de-duplicated downstream, the handshake is worth its energy. A command that opens a door strike, dispenses a dose or fires a relay has no natural key to collapse on, and a second execution has physical consequences. There the sequence is QoS 2 or, better, an application-level acknowledgement carrying the command id the device has already executed.

What a strong answer adds

That exactly-once is a property of a boundary, not of a protocol, and that the design question is always "where is the single place this can be made idempotent and what is the key". On a battery fleet, add the energy arithmetic: two extra round trips at roughly a second of radio time each, once every fifteen minutes, is a measurable fraction of a multi-year power budget.