messaging-rabbitmq-architect_skill

This skill designs robust RabbitMQ topologies, optimizing exchanges, queues, DLX, clustering, and reliability for durable, scalable messaging.
  • Python

5

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill williamzujkowski/cognitive-toolworks --skill messaging-rabbitmq-architect

  • SKILL.md23.1 KB

Overview

This skill designs production-ready RabbitMQ architectures covering exchanges, quorum and stream queues, routing patterns, clustering, dead letter exchanges, and AMQP best practices. I produce clear topology recommendations, queue arguments, publisher/consumer settings, and error handling patterns. The outputs are actionable: topology diagrams, configuration snippets, and operational rules to implement immediately.

How this skill works

For each requested message flow I validate RabbitMQ version and functional requirements, select exchange types and queue types (classic/quorum/stream) and generate routing and DLX retry patterns. I recommend publisher confirms, delivery modes, consumer ack strategies and prefetch tuning. For clustering and high-throughput scenarios I provide quorum replication, stream queue configuration, and federation or consistent-hash sharding patterns.

When to use it

  • Design a resilient production topology with replication and durability requirements
  • Implement DLX-based retries and dead-letter handling for failed messages
  • Choose between quorum queues and streams for durability vs throughput
  • Plan a multi-node cluster with Raft quorum and appropriate node counts
  • Shard high-volume workloads using consistent-hash exchanges or stream consumers

Best practices

  • Default to topic exchanges for flexible routing unless exact one-to-one mapping is required
  • Use quorum queues for production durability; streams for append-only, high-throughput use cases
  • Enable publisher confirms and delivery_mode=2 for durability; avoid AMQP transactions
  • Use manual consumer acks and start with prefetch=10, then tune based on processing profile
  • Implement DLX + TTL retry queues and a delivery-limit policy to avoid infinite redelivery
  • Run clusters with an odd number of nodes (3/5) and set x-quorum-initial-group-size accordingly

Example use cases

  • Single-exchange topology: events topic exchange → quorum order-processing-queue with confirms and prefetch=10
  • Multi-exchange routing: orders, payments, notifications exchanges with topic bindings and DLX for failed orders
  • Retry/backoff: retry-order-5s and retry-order-30s TTL queues that route back to main queue, final DLX for manual inspection
  • Clustering: 3-node cluster example, quorum queue replication and network/port requirements
  • High-throughput streaming: stream queue config with x-max-age and consumer offset strategies for audit/event logs

FAQ

Use quorum queues for replicated, durable workloads. Use stream queues when you need append-only log semantics and very high throughput.

How do I implement retries without losing ordering?

Use DLX + TTL retry queues for delays. For strict ordering use single active consumer (x-single-active-consumer=true) or route to a single shard so retries preserve order.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
messaging-rabbitmq-architect skill by williamzujkowski/cognitive-toolworks | VeilStrat