// Design RabbitMQ architectures with exchanges, quorum queues, routing patterns, clustering, dead letter exchanges, and AMQP best practices.
Analyzes and optimizes frontend performance using Core Web Vitals, bundle analysis, lazy loading, image optimization, and caching strategies
Design RESTful APIs with OpenAPI 3.1/3.2, resource modeling, HTTP semantics, versioning, pagination, HATEOAS, and OWASP API Security.
Design data pipelines with quality checks, orchestration, and governance using modern data stack patterns for robust ELT/ETL workflows.
Validate WCAG 2.2 compliance (A/AA/AAA) with ARIA, color contrast, keyboard navigation, screen readers, and automated testing via axe-core/Pa11y.
Design Kafka architectures with exactly-once semantics, Kafka Streams, ksqlDB, Schema Registry (Avro/Protobuf), performance tuning, and KRaft.
Configure Prometheus with alerting, recording rules, service discovery (K8s, Consul, EC2), federation, PromQL optimization, and Alertmanager.
| name | RabbitMQ Architecture Designer |
| slug | messaging-rabbitmq-architect |
| description | Design RabbitMQ architectures with exchanges, quorum queues, routing patterns, clustering, dead letter exchanges, and AMQP best practices. |
| capabilities | ["Exchange type selection and routing pattern design","Queue type selection (classic, quorum, streams)","Publisher confirms and consumer acknowledgments","Clustering topology with quorum queue replication","Dead letter exchange (DLX) error handling patterns","Message durability and persistence strategies","Prefetch tuning and consumer concurrency","AMQP protocol best practices"] |
| inputs | ["Message flow requirements (publishers, consumers, routing logic)","Exchange types (direct, topic, fanout, headers, consistent hashing)","Queue requirements (durability, replication, ordering, priority)","Clustering needs (high availability, replication factor)","Error handling patterns (DLX, retry, TTL)","Performance requirements (throughput, latency, consumer count)"] |
| outputs | ["RabbitMQ topology design (exchanges, queues, bindings)","Queue type recommendations (classic vs quorum vs streams)","Publisher/consumer configuration (confirms, acks, prefetch)","Clustering configuration (node count, replication)","DLX error handling setup","AMQP connection and channel management patterns"] |
| keywords | ["rabbitmq","amqp","message-queue","exchange","routing","quorum-queues","clustering","dead-letter-exchange","publisher-confirms","consumer-acknowledgments","message-broker","event-driven"] |
| version | 1.0.0 |
| owner | cognitive-toolworks |
| license | MIT |
| security | Never include credentials in topology definitions. Use environment variables for AMQP URIs. Enable TLS for production. Avoid hardcoding queue/exchange names with sensitive data. |
| links | [{"title":"RabbitMQ 4.1.0 Release (April 2025)","url":"https://www.rabbitmq.com/blog/2025/04/15/rabbitmq-4.1.0-is-released","accessed":"2025-10-26"},{"title":"Quorum Queues Documentation","url":"https://www.rabbitmq.com/docs/quorum-queues","accessed":"2025-10-26"},{"title":"RabbitMQ Exchanges","url":"https://www.rabbitmq.com/docs/exchanges","accessed":"2025-10-26"},{"title":"Clustering Guide","url":"https://www.rabbitmq.com/docs/clustering","accessed":"2025-10-26"},{"title":"Dead Letter Exchanges","url":"https://www.rabbitmq.com/docs/dlx","accessed":"2025-10-26"}] |
Trigger conditions:
Complements:
integration-messagequeue-designer: For generic message queue pattern selection (RabbitMQ vs Kafka vs SQS)messaging-kafka-architect: For Kafka-specific event streaming architecturesmicroservices-pattern-architect: For saga, CQRS, event sourcing patterns that use RabbitMQOut of scope:
observability-stack-configurator)Time normalization:
NOW_ET using NIST/time.gov semantics (America/New_York, ISO-8601)NOW_ET for all access dates in citationsVerify inputs:
Validate requirements:
Source freshness:
NOW_ET)Abort if:
Scenario: Single exchange, single queue, direct routing, no clustering, basic error handling.
Steps:
Exchange Type Selection:
order.created → order-processing-queue)* (1 word) and # (0+ words) (e.g., audit.events.# matches audit.events.users.signup)Queue Type Selection:
x-queue-type=quorum argumentPublisher Configuration:
Consumer Configuration:
Basic Topology:
events)order-processing-queue)order.created → order-processing-queue)events exchange with routing key order.createdorder-processing-queue with manual ack + prefetch=10Output:
Token budget: ≤2000 tokens
Scenario: Multiple exchanges with complex routing, dead letter exchange for errors, quorum queues, retry with backoff.
Steps:
Multi-Exchange Topology:
Pattern: Separate exchanges for different message types or bounded contexts
orders-exchange (topic) → routes to order-processing-queue, order-audit-queuepayments-exchange (topic) → routes to payment-processing-queuenotifications-exchange (fanout) → broadcasts to all notification queuesTopic Exchange Routing Patterns:
Wildcards:
* matches exactly one word (e.g., order.*.created matches order.online.created but not order.created)# matches zero or more words (e.g., audit.# matches audit.users, audit.users.signup, audit)Example bindings:
order.created → order-processing-queue (exact match)order.# → order-audit-queue (all order events)payment.processed → payment-processing-queuenotification.* → notification-email-queue, notification-sms-queue (broadcast via topic)Dead Letter Exchange (DLX) Setup:
Use cases:
Configuration via policy (recommended):
{
"pattern": "order-processing-queue",
"definition": {
"dead-letter-exchange": "dlx-exchange",
"dead-letter-routing-key": "order.processing.failed",
"message-ttl": 86400000,
"delivery-limit": 20
}
}
DLX topology:
order-processing-queue (quorum)dlx-exchange (topic)dlx-order-processing-queue (quorum, for manual inspection)order.processing.failed → dlx-order-processing-queueRetry with Backoff Pattern:
Pattern: Use TTL + DLX to implement delayed retries
retry-queue-5s (TTL=5s)Example:
order-processing-queueretry-order-5s (TTL=5s, DLX=orders-exchange)retry-order-30s (TTL=30s, DLX=orders-exchange)dlx-order-processing-queue (manual inspection)Quorum Queue Configuration:
Arguments:
x-queue-type=quorum (replicated queue)x-quorum-initial-group-size=3 (replication factor, odd number for Raft consensus)x-delivery-limit=20 (max redeliveries before DLX, default in RabbitMQ 4.0+)x-max-priority=2 (RabbitMQ 4.0+ supports exactly 2 priorities: normal and high)Publisher priority:
priority=5 (high priority, delivered 2:1 ratio vs normal)priority=0 or no priority (normal priority)Consumer Acknowledgment Strategies:
Manual ack (recommended):
basic.ack (remove from queue)basic.nack + requeue=true (redelivery)basic.nack + requeue=false (send to DLX)Prefetch tuning:
Output:
Token budget: ≤6000 tokens
Scenario: Multi-node cluster with quorum queue replication, stream queues for high throughput, federation for multi-DC.
Steps:
Clustering Topology:
Best practices:
Example 3-node cluster:
rabbit@node1.example.comrabbit@node2.example.comrabbit@node3.example.comQuorum queue replication:
x-quorum-initial-group-size)Stream Queues for High Throughput:
Use case: Event streaming, audit logs, high-volume data ingestion (millions of messages/sec)
Characteristics:
Configuration:
{
"x-queue-type": "stream",
"x-max-age": "7D",
"x-stream-max-segment-size-bytes": 500000000
}
Consumer offset tracking:
first, last, next, or timestampConsistent Hashing Exchange (Plugin):
Use case: Shard messages across multiple queues for horizontal scaling
Pattern:
Example:
sharded-orders (type=x-consistent-hash)orders-shard-0, orders-shard-1, orders-shard-2user-123 → always routes to same shardFederation for Multi-DC:
Use case: Replicate messages across datacenters without clustering (clusters require low-latency networks)
Pattern:
orders-exchangeorders-exchange-federated (receives messages from DC1)orders-exchangeBenefits:
Advanced Publisher Patterns:
Transactional publishing (avoid, heavyweight):
tx.select, tx.commit) → very slow, blocks channelBatch publishing:
Single Active Consumer (SAC) for Ordering:
Use case: Ensure messages processed in order by allowing only one consumer at a time
Configuration:
x-single-active-consumer=trueMessage Priority in Quorum Queues:
RabbitMQ 4.0+ feature:
priority=5 (high) or priority=0/unset (normal)Output:
Token budget: ≤12000 tokens
Exchange type selection:
Queue type selection:
Clustering decisions:
Prefetch tuning:
Error handling strategy:
nack + requeue=true (network timeout, downstream unavailable)nack + requeue=false → DLX (invalid data, schema mismatch)Abort conditions:
Topology schema:
exchanges:
- name: <exchange_name>
type: direct|topic|fanout|headers
durable: true|false
auto_delete: true|false
queues:
- name: <queue_name>
type: classic|quorum|stream
durable: true|false
arguments:
x-queue-type: quorum
x-quorum-initial-group-size: 3
x-delivery-limit: 20
x-max-priority: 2 # RabbitMQ 4.0+ only
x-single-active-consumer: true|false
bindings:
- exchange: <exchange_name>
queue: <queue_name>
routing_key: <pattern> # e.g., order.created, order.#, *
policies:
- name: <policy_name>
pattern: <queue_regex>
definition:
dead-letter-exchange: <dlx_exchange>
dead-letter-routing-key: <dlx_routing_key>
message-ttl: <milliseconds>
delivery-limit: 20
Publisher config:
# Publisher confirms
channel.confirm_delivery()
# Persistent messages
channel.basic_publish(
exchange='orders-exchange',
routing_key='order.created',
body=message,
properties=pika.BasicProperties(
delivery_mode=2, # persistent
priority=5 # high priority (RabbitMQ 4.0+)
)
)
Consumer config:
# Manual ack + prefetch
channel.basic_qos(prefetch_count=10)
def callback(ch, method, properties, body):
try:
process(body)
ch.basic_ack(delivery_tag=method.delivery_tag)
except TransientError:
ch.basic_nack(delivery_tag=method.delivery_tag, requeue=True)
except PermanentError:
ch.basic_nack(delivery_tag=method.delivery_tag, requeue=False) # → DLX
channel.basic_consume(queue='order-processing-queue', on_message_callback=callback)
Required fields:
exchanges[], queues[], bindings[]name, typename, type (classic/quorum/stream)exchange, queue, routing_keyTopology:
orders-exchange (topic)order-processing-queue (quorum, x-quorum-initial-group-size=3)dlx-exchange (topic)dlx-order-processing-queue (quorum, manual inspection)order.created → order-processing-queueorder.processing.failed → dlx-order-processing-queuePolicy (DLX config):
{
"pattern": "order-processing-queue",
"definition": {
"dead-letter-exchange": "dlx-exchange",
"dead-letter-routing-key": "order.processing.failed",
"delivery-limit": 20
}
}
Publisher:
channel.basic_publish(
exchange='orders-exchange',
routing_key='order.created',
body=json.dumps(order),
properties=pika.BasicProperties(delivery_mode=2)
)
Consumer:
def process_order(ch, method, properties, body):
try:
order = json.loads(body)
# Process order (may fail)
charge_payment(order)
ch.basic_ack(delivery_tag=method.delivery_tag)
except PaymentGatewayDown: # Transient error
ch.basic_nack(delivery_tag=method.delivery_tag, requeue=True)
except InvalidPaymentMethod: # Permanent error
ch.basic_nack(delivery_tag=method.delivery_tag, requeue=False) # → DLX
Token budgets:
Safety:
Auditability:
Determinism:
Performance:
Official Documentation:
NOW_ET)NOW_ET)NOW_ET)NOW_ET)NOW_ET)NOW_ET)NOW_ET)Client Libraries:
Related Skills:
integration-messagequeue-designer: Generic message queue pattern selectionmessaging-kafka-architect: Kafka-specific event streamingmicroservices-pattern-architect: Saga, CQRS, event sourcing with RabbitMQobservability-stack-configurator: Monitoring RabbitMQ with Prometheus + Grafana