You're sending telemetry from a fleet of battery-powered IoT devices over flaky cellular links. How do you decide on the messaging protocol and the delivery guarantees, for example MQTT QoS levels versus something like CoAP?

technical-conceptual · Mid level · software-engineering

What the interviewer is really asking

Assesses whether the candidate can choose an IoT application protocol on the real constraints — power/battery, network reliability, and required delivery semantics — understanding MQTT's broker/pub-sub model with QoS 0/1/2 versus CoAP's lightweight UDP request-response for ultra-constrained devices, and the trade-offs of each.

What to say

• Start from the device and network constraints: how tight is the power and memory budget, how lossy is the link, and does each message need a delivery guarantee? Those answers, not a favorite protocol, drive the choice.
• Place the options: MQTT is a broker-based pub/sub over TCP with tunable delivery via QoS — QoS 0 fire-and-forget (cheapest, may lose or duplicate), QoS 1 at-least-once (acked, but can duplicate so consumers must be idempotent), QoS 2 exactly-once (most overhead). It's strong for coordinating a fleet with retained state and offline queuing. CoAP is a lightweight UDP request/response, REST-like, built for ultra-constrained, battery-sensitive devices where TCP and a persistent broker connection would cost too much power.
• Map guarantee to data: pick QoS per topic, not globally — frequent sensor samples can ride QoS 0 since the next reading supersedes a lost one, while a command or a billing event wants QoS 1 with idempotent handling. On flaky cellular, weigh the cost of keeping a TCP/MQTT connection alive against CoAP's connectionless model, and lean on idempotency over the most expensive QoS 2.

What to avoid

• Defaulting every message to QoS 2 'to be safe', paying the highest handshake and power cost on a battery device when most telemetry would be fine at QoS 0 or 1.
• Ignoring the power and connection cost of holding a TCP/MQTT session open over cellular on a battery device, where CoAP's connectionless UDP might be the right call.
• Treating QoS 1 as exactly-once and skipping idempotent consumers, then being surprised by duplicate records when a redelivery happens.

Example answers

Strong: I'd decide from the constraints: power budget, how lossy the link is, and what guarantee each message actually needs. MQTT is broker-based pub/sub over TCP with QoS you can tune — 0 is fire-and-forget and cheapest, 1 is at-least-once but can duplicate so consumers must be idempotent, 2 is exactly-once and the most expensive. It's great for fleet coordination, retained state, and queuing while a device is offline. CoAP is a lightweight UDP request/response for ultra-constrained, battery-sensitive devices where holding a TCP connection and a broker session would drain power. I'd set QoS per topic, not globally: routine samples go QoS 0 because the next reading replaces a lost one, while commands or billing events go QoS 1 with idempotent handling. On flaky cellular I'd rather lean on idempotency than pay for QoS 2 everywhere, and I'd consider CoAP if the power budget can't afford a persistent connection.

Weak: I'd use MQTT with QoS 2 on everything so we never lose a message and never get duplicates — that's the safest setting. The broker handles reliability for us, so we don't really have to worry about the flaky network. CoAP I'd skip; MQTT is the more popular IoT protocol so it's the safer pick overall.