Direct answer

Use HTTP when one party addresses another for a bounded request and immediate response, especially where web infrastructure and third-party interoperability dominate. Use MQTT when intermittently connected devices need long-lived, brokered, bidirectional messaging with subscriptions and session state. A production IoT system often uses both: MQTT between devices and the messaging plane, HTTP for provisioning, administration, bulk transfer, and public APIs.

Scope and non-scope

This comparison concerns communication shape and operating model. It does not claim either protocol is a device-management platform. HTTP can be streamed and MQTT can implement request/response, but an exceptional pattern needs a concrete reason. Compare normal failure behavior, not only whether a demo can send bytes.

Decision criteria

Start with reachability. A device behind carrier NAT can open an outbound HTTP request or MQTT connection, but a server cannot normally initiate HTTP back to it. MQTT keeps an outbound connection through which the broker routes commands. Polling approximates this at the cost of request overhead, latency, and synchronized load; long polling and WebSockets change the architecture and should be evaluated separately.

Consider interaction shape. HTTP maps naturally to resource operations, uploads, downloads, and transactions with immediate status. MQTT maps naturally to asynchronous telemetry, events, desired state, and fan-out. Broker subscriptions decouple producers from consumer addresses, while HTTP usually requires an endpoint or a queue behind it.

Delivery semantics differ. HTTP confirms an exchange with a server, not the downstream outcome. MQTT QoS confirms broker protocol steps, also not the physical outcome. Both need idempotency and application acknowledgement for consequential commands. MQTT adds persistent sessions, retained messages, and offline queues, which are useful only when expiry and limits are designed.

Measure network cost with real behavior. MQTT’s compact header can help frequent small messages after a connection is established. TLS handshakes, keepalive, topic length, QoS acknowledgements, reconnects, HTTP headers, compression, and cellular billing increments can dominate theoretical differences. For an infrequent daily report, maintaining a connection may offer little value.

Operations matter. HTTP benefits from mature proxies, identity systems, tracing, caching, and familiarity. MQTT introduces broker capacity, connection admission, topic ACLs, session persistence, and queue recovery. Those are useful capabilities and additional responsibilities.

Architecture process

  1. List each flow: provisioning, telemetry, event, command, acknowledgement, firmware, configuration, and query.
  2. Record direction, cadence, payload, latency, offline expectation, fan-out, and consequence of failure.
  3. Select HTTP or MQTT per flow rather than declaring one protocol for the product.
  4. Define a shared identity and authorization model across both planes.
  5. Keep schemas independent enough to cross a gateway without losing identifiers, timestamps, or expiry.
  6. Test disconnect, retry, duplicate delivery, stale command, and service degradation.
  7. Observe end-to-end outcomes instead of treating a 2xx response or PUBACK as completion.

Failure modes

Frequent polling can create a thundering herd after an outage. Unbounded MQTT offline queues can deliver obsolete work after recovery. Retained messages used as event history replay the wrong semantics. Making every action synchronous HTTP couples availability to a long dependency chain. Turning every administrative query into MQTT request/response can make authorization, debugging, and timeouts harder than a conventional API. A dual-protocol design can drift when each path invents different identity or schemas.

Implementation checklist

  • Every flow has direction, cadence, latency, and offline requirements.
  • Protocol selection is made per flow with an explicit rationale.
  • Commands use idempotency, expiry, acknowledgement, and outcome state.
  • HTTP retries and MQTT redelivery cannot repeat unsafe effects.
  • Identity and tenant boundaries are consistent across both planes.
  • Reconnect and polling behavior is load-tested after shared outages.
  • Metrics distinguish transport success from business completion.
  • Bulk payloads and firmware use a deliberately chosen transfer path.

Review evidence

Preserve a flow inventory and sequence diagram showing which party initiates each exchange, what happens offline, and where success becomes durable. Capture network traces for representative small, large, and reconnect cases rather than quoting protocol overhead in isolation. Record retry and expiry defaults from the actual libraries. During review, ask whether a new gateway is translating semantics or merely changing transport: identifiers, authorization context, freshness, and outcome acknowledgements must survive the boundary. Revisit the choice when message cadence, reachability, cellular pricing, or third-party integration changes; protocol decisions are workload decisions, not permanent brand preferences.

Boundary review

When both protocols are used, define where translation occurs and which layer owns retries. A gateway must not acknowledge an HTTP request as complete merely because it published MQTT, nor acknowledge MQTT work because an HTTP server accepted a request. Preserve one application identifier across the boundary and record each terminal outcome.

Review credential scope separately. A device certificate for MQTT should not automatically authorize administrative HTTP APIs, and an API token should not become a wildcard MQTT principal. Apply consistent tenant and device identity while retaining least privilege per flow. Test observability across the handoff so operators can follow one request without logging secrets or full payloads.

Finally, document degraded modes. Decide whether provisioning failure blocks telemetry, whether command delivery continues during API outage, and how bulk downloads avoid starving messaging. Explicit boundaries make a mixed design resilient; undocumented coupling merely hides two protocols behind one outage.

Primary sources

The OASIS MQTT 5.0 specification defines sessions, QoS, subscriptions, retained messages, and expiry. The IETF HTTP Semantics specification, RFC 9110 defines methods, status semantics, intermediaries, and retry considerations. Validate SDK and infrastructure behavior in the target networks.