RabbitMQ Architecture Diagram: Exchanges, Queues & Routing Patterns (2026)
How to create RabbitMQ architecture diagrams. Covers exchanges, queues, bindings, routing keys, dead letter queues, publisher confirms, and consumer ack patterns — with AI prompt templates.
R
Ryan·Senior AI Engineer
RabbitMQ architecture diagrams visualize the message broker topology that routes messages between producers and consumers through a network of exchanges, queues, and bindings. Unlike Kafka's log-centric model, RabbitMQ is a push-based broker optimized for complex routing logic — direct routing, fan-out broadcast, topic-based filtering, and header matching — with messages being consumed and removed from the queue rather than retained for replay. A RabbitMQ architecture diagram makes the routing topology legible: showing which exchanges receive messages, how bindings route them to queues, and which consumers process each queue.
This guide covers RabbitMQ's core building blocks, common topology patterns, and prompt templates for generating accurate diagrams with AI.
Core components of a RabbitMQ architecture diagram
- Producers: Applications that publish messages to an exchange. Producers specify the exchange name and a routing key. With publisher confirms enabled, the broker acknowledges each message once it has been persisted (durable) or routed to at least one queue.
- Exchanges: The routing layer. Exchanges receive messages and route them to zero or more queues based on the exchange type and bindings. The four exchange types — direct, fanout, topic, and headers — each represent a different routing strategy and should be clearly labeled on the diagram.
- Bindings: Rules that connect an exchange to a queue, optionally filtered by a routing key (for direct and topic exchanges) or header values (for headers exchanges). Each binding arrow on a diagram should carry the binding key or pattern.
- Queues: Buffers that hold messages until a consumer processes them. Annotate each queue with its durability (durable survives broker restart), whether it is exclusive (bound to a single connection), auto-delete behavior, and message TTL.
- Consumers: Applications that subscribe to a queue and process messages. Label each consumer with its acknowledgment mode: auto-ack (message deleted on delivery, risk of data loss) or manual-ack (message deleted only after the consumer calls basicAck).
- Dead Letter Exchanges (DLX): When a message is rejected, times out, or exceeds the queue's max-length, it can be routed to a Dead Letter Exchange (DLX) and from there to a dead letter queue (DLQ) for inspection and retry. Show the DLX and DLQ as a parallel path on the diagram.
- Virtual hosts (vhosts): Logical namespaces within a RabbitMQ broker that provide isolation between tenants or environments. Draw a boundary box around each vhost when your diagram spans multiple environments or teams.
- Cluster and quorum queues: For high availability, RabbitMQ can be clustered across multiple nodes. Quorum queues (Raft-based, recommended over classic mirrored queues) replicate messages across a majority of nodes. Show node count and queue type (classic vs. quorum) when HA matters.
Exchange types and when to use each
| Exchange type | Routing logic | Best for | Example |
|---|---|---|---|
| Direct | Exact routing key match | Task queues, work distribution | key "email" → email queue |
| Fanout | Broadcast to all bound queues | Pub/sub, cache invalidation | Order event → 3 queues |
| Topic | Wildcard key pattern (*, #) | Event routing by category/region | us.*.order → US order queue |
| Headers | AMQP header attribute match | Multi-attribute routing without key | format=pdf AND type=report |
Prompt examples for common RabbitMQ patterns
Work queue (task distribution)
"A RabbitMQ work queue pattern: three producer services (API Server 1, 2, 3) publish tasks with routing key 'video.transcode' to a direct exchange named 'tasks'. The exchange routes to a single durable queue 'video-transcode-queue' (prefetch count 1 for fair dispatch). Four Transcoder Worker consumers subscribe with manual-ack. Failed messages (after 3 retries via x-death header count) are routed via a Dead Letter Exchange 'tasks.dlx' to a dead letter queue 'video-transcode-dlq', consumed by an ops monitoring service."
Publish/subscribe with fanout exchange
"An order lifecycle pub/sub: the Order Service publishes to a fanout exchange named 'order.events'. The exchange broadcasts to three queues: 'order-notifications-queue' (consumed by Notification Service — sends email/SMS), 'order-inventory-queue' (consumed by Inventory Service — decrements stock), and 'order-analytics-queue' (consumed by Analytics Worker — writes to Snowflake). All queues are durable with message TTL 24h. Each consumer uses manual ack. Failed messages go to per-service DLQs."
Topic exchange with regional routing
"A multi-region RabbitMQ setup using a topic exchange 'payments'. Payment services publish with routing keys like 'us.card.approved', 'eu.card.declined', 'us.bank.pending'. Bindings: 'us.#' → 'us-payments-queue' (US processing team), 'eu.#' → 'eu-payments-queue' (EU processing team), '*.card.*' → 'card-fraud-queue' (Fraud Detection Service subscribes to all card transactions regardless of region). All queues are quorum queues on a 3-node cluster for HA."
Request/reply (RPC over RabbitMQ)
"A RabbitMQ RPC pattern: a Client Service publishes a request message to the 'rpc-requests' queue with a correlationId and a replyTo property pointing to a temporary exclusive auto-delete queue generated per request. The Pricing Engine Worker processes requests from 'rpc-requests', computes the price, and publishes the response to the replyTo queue. The client blocks until the response arrives (or times out after 5 seconds). Each worker instance uses prefetch 10 for throughput."
RabbitMQ vs Kafka: choosing the right message system
- Choose RabbitMQ when you need complex routing logic (topic/header exchanges), your consumers must process and delete messages (no replay needed), you want push-based delivery with per-message acknowledgment, or you're working with AMQP-native client libraries (Java, .NET, Python).
- Choose Kafka when you need event replay and rewind, high-throughput streaming (millions of messages/second), exactly-once semantics, or you want consumers to read at their own pace from a durable log. Kafka retains messages regardless of consumption.
- Use both together when RabbitMQ handles task queues and synchronous-style RPC flows, while Kafka handles event streaming, CDC, and analytics pipelines in the same system.
What to annotate on a RabbitMQ diagram
- Exchange type: Label each exchange with its type (direct, fanout, topic, headers) — this is the most important routing information on the diagram
- Binding keys: Show the routing key or pattern on every binding arrow — without this, the diagram doesn't explain how messages are routed
- Queue durability: Mark queues as durable (survive restart) or transient — transient queues lose messages on broker restart, which surprises teams who don't model this explicitly
- Ack mode: Label each consumer with auto-ack or manual-ack — auto-ack is dangerous for tasks that require at-least-once processing
- DLX/DLQ paths: Always show the dead letter path — it's critical for understanding what happens to messages that fail or expire
Related guides: Kafka architecture diagrams, event sourcing and CQRS, microservice architecture patterns, and streaming data architecture.
Ready to try it yourself?
Start Creating - Free