AMQP · Study deck

MQTT and AMQP: Routing Architectures

MQTT and AMQP are not rivals so much as tools for different parts of the route.

Broker Bex is your guide for this deck.

mqttcases

Broker Bex, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Trace architecture comparison: mqtt vs amqp data flow across its components and failure boundaries.
Define amqp and mqtt hybrid bridge contracts with explicit inputs, errors, and change rules.
Decide whether MQTT, AMQP, or a hybrid bridge owns each layer of an IoT system.
Compare MQTT topics, retained messages, QoS, and Last Will behavior with AMQP exchanges, queues, acknowledgments, and dead-letter routing.

Major section

Architecture Comparison: MQTT vs AMQP Data Flow

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.

MQTT architecture showing IoT sensors publishing to topic hierarchy with broker distributing messages to multiple subscribers

Major section

Hybrid Architecture Pattern

The edge broker keeps that uplink light and collects many device streams.

At the center, stop at the protocol bridge rather than jumping straight to AMQP: topic mapping, stable identifiers, buffering, and replay all cross this boundary.
Someone must own its backlog and duplicate policy when either side is unavailable.

The hybrid keeps lightweight MQTT at the edge and uses an owned reliability bridge before AMQP routes work to backend queues.

Major section

AMQP and MQTT Hybrid Bridge Contracts

The bridge is the border checkpoint that must preserve identity, routing meaning, replay rules, and monitoring evidence.

A protocol is an agreed set of exchange rules.
Telemetry is a time-linked record of a device or process.
Quality of service is a named delivery level, not proof that a business action happened.

Protocol choice is a placement decision: MQTT usually owns constrained uplink, AMQP owns backend routing, and a bridge connects the two when both constraints matter.

Major section

AMQP and MQTT Hybrid Bridge Contracts (continued)

Message queuing telemetry transport (MQTT) is often used by devices to publish readings.

Advanced message queuing protocol (AMQP) is often used for richer service workflows.
The bridge must keep identity, time, unit, quality, and message age.
This evidence proves the named mapping and limits.
Many real systems use both.

Major section

AMQP and MQTT Hybrid Bridge Contracts (continued)

The wildcard difference is another migration trap.

If it changes a topic into a route but loses those fields, a valid delivery can still create a wrong action.
AMQP vs MQTT and Use Cases compares protocol overhead, feature fit, battery impact, decision trees, and hybrid architecture.
The bridge needs its own reliability contract.

Major section

AMQP and MQTT Hybrid Bridge Contracts (continued)

MQTT and AMQP are both publish/subscribe, but they are tuned for opposite ends of an IoT system.

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.

AMQP architecture with exchange-based routing showing producer sending to topic exchange which routes messages to multiple queues based on binding patterns

Major section

AMQP and MQTT Hybrid Bridge Contracts (continued)

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.

A telling detail: MQTT's retained message keeps the last value on a topic for new subscribers, which suits state ("current temperature").
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.

Deck summary

Key takeaways

Exchanges decide matches while queues decouple delivery and processing.

The edge broker keeps that uplink light and collects many device streams.
The bridge is the border checkpoint that must preserve identity, routing meaning, replay rules, and monitoring evidence.
Message queuing telemetry transport (MQTT) is often used by devices to publish readings.
The wildcard difference is another migration trap.

Retrieval practice

Recall check 1 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q1A chapter table quotes $96/year for 50,000 AWS IoT Core devices and a fixed RabbitMQ cluster cost, but gives no connection duration, message rate, region or rules usage. What is the defensible cost conclusion for a real deployment?

AMQTT and AMQP cost the same because both can use cloud-hosted brokers.

BDevice count cannot price it; model traffic and broker operations for both.

CAMQP costs $96 yearly while MQTT needs a fixed $15,000 setup.

DOpen-source protocols remove every infrastructure cost at scale.

Show answer

Answer: B The table's $96/year for 50,000 AWS IoT Core devices is not a reproducible total without connection minutes, messaging volume, region and optional component use.

Retrieval practice

Recall check 2 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q2What translates MQTT telemetry into AMQP routing and delivery policies?

AMQTT-to-AMQP Bridge

BMQTT Field Devices

CAMQP Enterprise Services

Show answer

Answer: A The bridge changes topic-based telemetry into AMQP exchanges, routing keys, delivery policies, and failure handling.

Q3Complete the hybrid architecture bridge that subscribes to MQTT and republishes to AMQP:

Aamqp_channel.basic_publish(exchange='iot_bridge', routing_key=routing_key, body=msg.payload)

Bamqp_channel.send(exchange='iot_bridge', key=routing_key, data=msg.payload)

Camqp_channel.publish(exchange='iot_bridge', routing_key=routing_key, body=msg.payload)

Damqp_channel.basic_send(exchange='iot_bridge', routing_key=routing_key, body=msg.payload)

Show answer

Answer: A The bridge subscribes to MQTT topics using '#' wildcard (all subtopics) and republishes to AMQP using basic_publish.

Retrieval practice

Recall check 3 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q4For 20,000 meters each sending a 50-byte reading once a minute, what rates result from the Overview's incomplete illustrations of payload plus 2 bytes for MQTT or 8 bytes for AMQP (not complete protocol bandwidth)?

AMQTT is about 173 KB/s and AMQP is about 193 KB/s, ten times higher because of TLS overhead

BMQTT illustration about 17.3 kB/s; AMQP illustration about 19.3 kB/s; neither is a complete bandwidth estimate.

CMQTT and AMQP use exactly the same bandwidth because both send the same 50-byte payload

DAMQP is far cheaper than MQTT because its exchange overhead replaces the need for TLS

Show answer

Answer: B see answers page

Retrieval practice

Recall check 4 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q5Per this chapter's Practitioner section, why does AMQP have no equivalent to MQTT's retained message?

AMQTT has a retained last-value-per-topic feature; AMQP 0-9-1 queues represent pending deliveries rather than that retained-state contract

BBecause AMQP uses transient messages for live telemetry, leaving long-term state storage to the receiving application rather than the broker's own queue storage

CBecause MQTT retained values can become stale after a device disconnects, AMQP replaces retained state with message expiry to keep late consumers from acting on old readings

DBecause AMQP consumers retrieve state by polling a queue for the newest reading, while MQTT sends a retained reading when a client subscribes to the topic

Show answer

Answer: A MQTT retained messages model a latest value on a topic for a new subscriber.

Retrieval practice

Recall check 5 of 5

Broker Bex says: answer from memory, then check your reasoning.

Q6A fleet of constrained cellular sensors must send telemetry cheaply, and the backend must route it to several services with durable queues, load-balanced workers, and a dead-letter path. What architecture fits best?

AAMQP directly on every sensor, because one protocol is simpler than two.

BMQTT from devices to an edge broker, bridged to an AMQP topic exchange.

CMQTT everywhere, adding queues and dead-lettering in the MQTT broker.

DHTTP polling from each sensor to keep the stack uniform.

Show answer

Answer: B Use MQTT for constrained edge telemetry and bridge into AMQP 0-9-1 for the specified exchange, queue, competing-worker and dead-letter contracts.

Print reference

Answers 1 of 3

Answer key.

B · The table's $96/year for 50,000 AWS IoT Core devices is not a reproducible total without connection minutes, messaging volume, region and optional component use.
A · The bridge changes topic-based telemetry into AMQP exchanges, routing keys, delivery policies, and failure handling.
A · The bridge subscribes to MQTT topics using '#' wildcard (all subtopics) and republishes to AMQP using basic_publish.

Print reference

Answers 2 of 3

Answer key.

B · Using the Overview's incomplete illustrations: 20,000 x (50 + 2) / 60 = 17.3 kB/s for MQTT and 20,000 x (50 + 8) / 60 = 19.3 kB/s for AMQP. These are payload-plus-header illustrations, not complete publishes or a cross-protocol link budget. Include the omitted protocol and transport bytes before estimating bandwidth or costs.
A · MQTT retained messages model a latest value on a topic for a new subscriber.

Print reference

Answers 3 of 3

Answer key.

B · Use MQTT for constrained edge telemetry and bridge into AMQP 0-9-1 for the specified exchange, queue, competing-worker and dead-letter contracts.