18 MQTT and AMQP: Routing Architectures

18.5.1 MQTT: Simple Pub/Sub Architecture

Inspect Figure 18.1 to understand the compact routing model that makes MQTT attractive at the device edge.

+

Trace Figure 18.1 from sensor publishes into the topic hierarchy, then follow matching subscriptions to their consumers. The broker mediates fan-out without separate application-visible queues and bindings. That simplicity reduces device-side burden while leaving durable backend work distribution to another layer when needed.

MQTT Characteristics:

• Overhead: 2-byte fixed header minimum
• Routing: Simple topic matching (sensors/+/temp)
• Throughput: 166.7 msg/sec for 50,000 devices at 5-min intervals, easily handled by single broker
• Cost: ~$96/year for AWS IoT Core (50K devices)

18.5.2 AMQP: Advanced Routing Architecture

Inspect Figure 18.2 to see where AMQP adds routing state beyond a simple topic subscription.

+

Trace Figure 18.2 from producer to exchange, then evaluate bindings into distinct queues before following consumers. Exchanges decide matches while queues decouple delivery and processing. That separation enables backend fan-out and work distribution, but it also creates topology and failure policies the operator must own.

AMQP Characteristics:

• Overhead: 8-byte frame header + exchange routing
• Routing: Complex binding patterns with wildcards (zone..fire.)
• Guarantees: Transactional delivery with acknowledgments and dead-letter queues
• Cost: ~$15K setup + $5K/year maintenance for RabbitMQ cluster

18.10.1 Learning Objectives

18.10.2 Why This Follows AMQP vs MQTT

AMQP vs MQTT and Use Cases compares protocol overhead, feature fit, battery impact, decision trees, and hybrid architecture. This page tightens the production contract for the hybrid case: MQTT usually carries constrained device uplink, AMQP usually owns backend routing and work queues, and the bridge becomes a reliability boundary that must preserve enough metadata to replay safely.

Use it when a design review needs more than “MQTT at the edge, AMQP in the backend”: the bridge must define topic-to-routing-key mapping, replay ownership, failure back-pressure, deduplication, and the metrics that prove neither side is silently falling behind.

18.10.3 Overview: They Optimize for Different Ends of the System

MQTT and AMQP are both publish/subscribe, but they are tuned for opposite ends of an IoT system. MQTT is a deliberately tiny wire protocol for constrained devices on flaky links: a 2-byte minimum header, three QoS levels, retained messages, and a Last Will and Testament so the broker announces a device that dropped off. AMQP 0-9-1 is a richer broker protocol for the server side: first-class exchanges, queues, and bindings, plus acknowledgements, publisher confirms, and dead-letter routing for reliable work distribution.

Inspect Figure 18.4 to decide where each protocol belongs before treating MQTT and AMQP as interchangeable publish-subscribe choices.

+

Read Figure 18.4 from device constraints to routing and work-handling needs. Lightweight, intermittent uplinks point toward MQTT; broker-side queues, richer routing, and replay controls point toward AMQP; mixed constraints lead to a bridge. The route establishes the ownership boundaries that the rest of the chapter must make reliable.

The honest summary is not "which is better" but "which layer": MQTT gets telemetry off the device cheaply; AMQP routes and processes it reliably in the backend. Many real systems use both. Start the decision with three questions: is the publisher constrained, does routing need broker-side fan-out or work queues, and must failed work be parked for replay? "Yes" to the first pushes toward MQTT; "yes" to the second or third pushes toward AMQP behind the ingestion edge.

For 20,000 50-byte readings per minute, 17.3 kB/s is only the payload plus a 2-byte minimum MQTT fixed-header lower bound; a link budget must also include topic-name bytes, remaining-length encoding, packet identifiers when used, TCP and TLS (HiveMQ protocol comparison). The 19.3 kB/s AMQP figure counts payload plus one 8-byte frame-header illustration, not a complete publish. Use an encoded example or remove this cross-protocol bandwidth claim.

When a design review cannot name the constrained link, the routing rule, and the replay owner, it is too early to pick a single protocol.

18.10.4 Practitioner: Mechanism-by-Mechanism

A telling detail: MQTT's retained message keeps the last value on a topic for new subscribers, which suits state ("current temperature"). AMQP has no retained concept because it queues every message for durable consumption, which suits work ("process each order"). Reach for the model whose default matches your data.

Use this as an implementation checklist. If a device publishes status that will be superseded by the next sample, MQTT retained messages and QoS 1 are usually enough. If an order, alarm, or command must be processed once by a worker pool, AMQP's durable queue plus manual ACK is a better fit. If a message must reach several independent backends, MQTT subscribers can all receive it, but each subscriber owns its own durability story; AMQP can route one publish into separate durable queues with independent retry and dead-letter policies.

The wildcard difference is another migration trap. MQTT topic site/+/temp maps naturally to AMQP routing key pattern site.*.temp, but MQTT site/# means the rest of the slash-separated tree and must be a final token, while AMQP # matches zero or more dot-separated words. Bridge tests should include site/floor1/temp, site/floor1/room7/temp, and site so the mapping does not accidentally drop deeper telemetry.

18.10.5 Under the Hood: The Hybrid Edge-to-Backend Bridge

Because they fit different layers, the common production shape is a hybrid: devices speak MQTT to a broker at the edge, and a bridge republishes those messages into AMQP for backend routing and durable work queues. A broker plugin or bridge maps an MQTT topic onto an AMQP topic-exchange routing key, translating the MQTT / separator to the AMQP . separator -- so MQTT topic sensor/floor1/temp becomes AMQP routing key sensor.floor1.temp, which AMQP bindings then match with * and #.

Worked example. Ten thousand battery sensors publish MQTT QoS 1 to an edge broker on topic site/<id>/temp. A bridge feeds those into an AMQP topic exchange as site.<id>.temp. In the backend, a data-lake queue binds site.# (store everything, durable, persistent), while an alerting service binds site.*.temp behind competing consumers with a modest prefetch, and rejects unprocessable messages to a dead-letter queue. Each protocol does what it is best at: MQTT for cheap, resilient uplink; AMQP for durable, richly-routed, load-balanced processing.

The bridge needs its own reliability contract. Preserve the MQTT packet identifier, client identifier, topic, QoS, and capture time as AMQP headers, then add an idempotency key before publishing into AMQP. If the AMQP broker blocks publishers, the bridge should stop acknowledging or committing MQTT-side intake rather than losing data in an in-memory buffer. A practical limit is a bounded local spool: for 10,000 sensors sending one message per minute, a 10-minute backend outage is about 10,000 x 10 = 100,000 records, so the bridge storage and replay rate must be sized deliberately.

Operationally, monitor both sides. MQTT metrics tell you connected clients, keepalive failures, retained-message count, and incoming message rate. AMQP metrics tell you exchange publish rate, queue depth, unacknowledged messages, dead-letter rate, and consumer drain rate. A healthy hybrid bridge keeps those curves aligned: MQTT ingress equals AMQP publish plus bounded spool growth, and AMQP queue age stays inside the business SLA.