RabbitMQ MQTT Plugin IoT Broker Prompt
Configure the RabbitMQ MQTT plugin as an IoT-facing broker — topic-to-routing-key mapping, QoS handling, per-device auth, and connection limits — without breaking AMQP consumers.
- Target user
- Platform engineers bridging MQTT devices into RabbitMQ
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who has run the RabbitMQ MQTT plugin at the edge with thousands of device connections. Help me configure it safely alongside my AMQP workloads. I will provide: - Device fleet: connection count, message rate per device, QoS levels used (0/1/2), and clean-session behavior [DESCRIBE] - Topic structure devices publish/subscribe to, and the AMQP consumers that need to read those messages [DESCRIBE] - Auth model: per-device credentials, x509 client certs, or a token gateway [DESCRIBE] - Cluster details: node count, RAM, RabbitMQ version, whether the MQTT and Web MQTT plugins are enabled [DESCRIBE] Your job: 1. **Map MQTT to AMQP correctly** — explain how MQTT topics map to the `amq.topic` exchange routing keys (`/` becomes `.`), how subscriptions create transient queues, and what my AMQP consumers must bind to in order to receive device messages. 2. **QoS translation** — MQTT QoS 0/1/2 does not map 1:1 to AMQP. Explain what the plugin actually guarantees (QoS 2 is downgraded), and the durability implication for messages that must not be lost. 3. **Connection scale and limits** — set `mqtt.subscription_ttl`, durable vs transient subscriber queues, per-connection memory, and node connection limits. Flag the cost of thousands of transient queues from clean-session reconnect churn. 4. **Auth and isolation** — per-device credentials vs x509, vhost isolation for device traffic, and `mqtt.allow_anonymous false`. Make sure a compromised device can't publish to internal AMQP routing keys. 5. **Validate** — what to watch: MQTT connection count, transient queue churn, memory per connection, and AMQP consumer lag on the bridged exchange. Output as: (a) the topic-to-routing-key mapping with a concrete binding for AMQP consumers, (b) the QoS/durability guidance, (c) the connection-limit and TTL config, (d) the auth/isolation settings, (e) the metrics to watch. Validate the MQTT-to-AMQP bridge on a staging broker with simulated device load before pointing real devices at it. Reconnect churn from clean-session devices can flood the broker with transient queue creation — load-test the churn, not just the steady state.
Why this prompt works
The MQTT plugin makes RabbitMQ a credible IoT broker, but it hides a translation layer that bites teams who assume MQTT semantics carry through to AMQP. This prompt’s first job is making that mapping explicit: MQTT topics land on the amq.topic exchange with / rewritten to ., subscriptions spin up transient queues, and AMQP consumers have to bind correctly to see any device traffic at all. Skip that and you get a broker that accepts device publishes while your backend silently receives nothing.
The QoS section addresses the most dangerous false assumption — that MQTT QoS 2 gives you exactly-once across the bridge. It doesn’t; the plugin downgrades it, so the prompt pushes idempotent AMQP consumers instead of pretending the guarantee exists. That single reframing prevents a class of “we lost device messages” and “we processed it twice” incidents that QoS misunderstandings cause.
The scale and auth sections target the two things that actually take MQTT deployments down: reconnect churn from clean-session devices hammering transient-queue creation, and weak device isolation letting one compromised credential publish into internal routing keys. By demanding connection limits, subscription TTLs, vhost isolation, and a load test of the churn rather than the steady state, the prompt protects the broker where IoT traffic really stresses it. The staging guardrail makes the churn test non-optional.