AMQP Exchange Configuration Simulator — Map Routing Keys and Queue Bindings

How to Use the AMQP Exchange Config Builder:

1. Load a Preset (Optional): Click any preset to pre-fill all fields with a common RabbitMQ pattern. Task queue shows a direct exchange routing messages to two queues by routing key. Pub/Sub broadcast shows a fanout exchange delivering to all bound queues simultaneously. Log routing demonstrates a topic exchange with wildcard patterns. Dead letter shows an internal direct exchange for failed messages. All presets are editable after loading.

2. Enter an Exchange Name: Type the name of the exchange to declare. Exchange names are arbitrary strings — common conventions use lowercase with hyphens or dots (tasks, payments.events, user.notifications). Spaces are not allowed.

3. Select the Exchange Type: Choose from four types. Direct routes messages to queues whose binding key exactly matches the message routing key — ideal for task queues and targeted dispatch. Fanout ignores routing keys entirely and broadcasts every message to all bound queues — ideal for pub/sub and fan-out notification systems. Topic routes by routing key pattern using * (matches exactly one word) and # (matches zero or more words) — ideal for event-driven log routing and multi-tenant systems. Headers routes based on message header attributes instead of routing key — useful when routing logic depends on message metadata.

4. Set Exchange Options: Durable means the exchange survives a broker restart — use this for production exchanges. Auto-delete removes the exchange automatically when the last queue unbinds from it — useful for temporary or session-scoped exchanges. Internal means the exchange can only receive messages forwarded from other exchanges, not from publishers directly — used in exchange-to-exchange routing and dead-letter configurations.

5. Add Queue Bindings: Each binding declares a queue and binds it to the exchange. Enter the queue name and routing key for each binding. For fanout exchanges, the routing key is ignored and left blank automatically. For topic exchanges, use * to match a single word segment and # to match zero or more segments. Queue options: Durable means the queue survives a broker restart. Exclusive means the queue is tied to the connection that declared it and deleted when the connection closes. Auto-delete removes the queue when the last consumer disconnects. Click Add to add up to five bindings.

6. Choose a Language: Toggle between Node.js and Python to switch the output language. The Node.js output uses amqplib with async/await. The Python output uses pika's BlockingConnection API.

7. Copy and Use the Code: Click Copy to copy the full setup function to the clipboard. Paste it into your project and replace the amqp://localhost connection string with your actual broker URL. The generated code declares the exchange and all bound queues — run it once during application startup or as a separate setup script.

Common Use Cases:

• New RabbitMQ integration: Scaffold the exchange and queue declarations for a new service without writing boilerplate from memory.
• Architecture documentation: Use the presets as visual references to compare exchange types when planning a message-driven system.
• Multi-language teams: Generate the same topology in both Node.js and Python to ensure both services declare identical exchanges and queues.
• Dead letter exchange setup: Use the Dead letter preset as a starting point for configuring DLX routing in an existing queue topology.
• Topic routing design: Test routing key patterns in the topic preset to verify that * and # wildcards match the queue you expect before deploying.

Tips and Best Practices:

• Always declare exchanges and queues as durable in production. Non-durable exchanges and queues are lost on broker restart and can cause message loss.
• Declare the same exchange from both producer and consumer code. RabbitMQ is idempotent for declarations with matching parameters, so duplicate declarations are safe.
• For topic exchanges, use a consistent dot-separated routing key convention: service.entity.event (e.g., payments.invoice.created). This makes wildcard patterns predictable.
• An exclusive queue is deleted when its connection closes — use it only for temporary reply queues in request-reply (RPC) patterns.
• The internal option is for exchange-to-exchange routing. If you need a dead-letter exchange that publishers cannot accidentally send to, mark it as internal.