The short answer

MQTT is a lightweight stateful messaging protocol; it is not a device model, storage engine, or complete IoT platform.

MQTT is designed for long-lived client connections and asynchronous message exchange through a broker. A publisher sends a message to a topic; the broker matches that topic against subscriptions and forwards the message to interested clients. The publisher does not need to know who receives it, and subscribers do not need to know where it originated.

That separation is useful, but it moves important responsibilities into the protocol contract and the broker. Session expiry, retained messages, will messages, inflight limits, topic authorization, and reconnect behavior all affect production outcomes. MQTT is small on the wire; operating it well is not automatically simple.

Why teams choose MQTT

MQTT fits fleets that maintain outbound connections, publish telemetry, receive commands, and may lose network access temporarily. Because the device opens the connection, deployments usually avoid exposing device-side listening ports through carrier NAT or customer firewalls. The broker also gives many producers and consumers a shared routing point without requiring every service to call every device directly.

The protocol is especially useful when the same event feeds several consumers, such as live operations, rules, storage, and audit. Subscriptions can evolve without changing the publishing device, provided the topic and payload contracts remain compatible.

MQTT does not remove the need for application APIs. Provisioning, bulk export, firmware artifact delivery, and user-facing request/response workflows often remain better suited to HTTPS.

How it works

A client establishes a network connection, normally over TCP with TLS, and sends CONNECT. The broker accepts or rejects the connection and may resume an existing session. Publishers send PUBLISH packets with a topic, payload, retain flag, and QoS. Subscribers register topic filters, which may include + or # wildcards, and the broker performs the match.

QoS is hop-by-hop delivery machinery:

  • QoS 0 sends once without an MQTT acknowledgement.
  • QoS 1 uses acknowledgements and may deliver duplicates.
  • QoS 2 adds a multi-step exchange to avoid duplicate delivery at the MQTT protocol layer.

None of the levels proves that a downstream business action happened exactly once. A consumer may finish work and crash before recording its acknowledgement, or the same real-world event may be published more than once. Important consumers still need stable event identifiers, idempotent handling, and explicit outcome records.

Retained messages store the latest retained publication for future subscribers; they are not an offline job queue. Persistent sessions can preserve subscriptions and queued messages while a client is disconnected, but only within configured expiry and resource limits. Will messages let the broker publish when a connection ends unexpectedly; they are a useful signal, not definitive diagnosis of device health.

What MQTT solves

MQTT provides a standard message envelope, topic-based routing, subscription state, delivery handshakes, and connection liveness. MQTT 5 also adds richer reason codes, session expiry, flow-control properties, response topics, and user properties. These features can make failures more observable and contracts more explicit.

It is a good fit for telemetry fan-out, asynchronous commands, state notifications, gateway-to-platform exchange, and intermittent clients that need bounded session continuity.

What it does not solve

MQTT does not define a device identity lifecycle, payload schema, thing model, tenant model, command authorization policy, long-term storage format, or business workflow. TLS can authenticate endpoints and protect traffic, but the product still needs credential issuance, rotation, revocation, ownership transfer, and per-topic authorization.

A broker cluster is also not a universal high-availability answer. Authentication services, DNS, load balancers, certificate infrastructure, storage, and downstream consumers can become the limiting dependency during a reconnect storm.

Where it fits—and where it does not

Use MQTT when clients benefit from durable outbound connections, asynchronous many-to-many routing, and explicit offline behavior. It is less attractive for rare one-shot requests from environments where an HTTP stack already provides all required behavior, for large file transfer, or for hard real-time control loops. Industrial safety and motion control need deterministic local mechanisms; MQTT may report or coordinate those systems, but should not replace their safety layer.

Related technologies include an MQTT broker, TLS, device identity, topic ACLs, retained state, device shadows, Sparkplug B, and time-series storage. Sparkplug adds an industrial namespace and lifecycle contract on top of MQTT. A device shadow adds desired/reported state semantics that MQTT itself does not define.

Common misconceptions

“MQTT guarantees exactly once” confuses protocol delivery with business effects. “MQTT is always lower bandwidth than HTTP” ignores connection frequency, TLS setup, topic length, payload size, and traffic shape. “The broker is the IoT platform” overlooks provisioning, state, rules, data, operations, and product workflows. Finally, “connected means online” ignores half-open paths and stale application state; use heartbeats and domain-specific freshness rules instead of connection status alone.

For production, specify topic ownership, payload versions, QoS rationale, session expiry, queue limits, reconnect jitter, maximum packet size, and negative authorization tests before choosing a broker implementation.