đź’» DĂ©veloppement

message-queue-architect

Architecture de messaging avec RabbitMQ, Kafka, Azure Service Bus.

⚡ Installation & lancement en 1 commande

Copiez-collez dans votre terminal : le skill s'installe dans ~/.claude/skills et Claude Code se lance directement dessus.

macOS / Linux
curl -fsSL https://raw.githubusercontent.com/khalilbenaz/claude-skills-collection/main/install.sh | sh -s -- message-queue-architect --launch
Windows (PowerShell)
iex "& { $(iwr -useb https://raw.githubusercontent.com/khalilbenaz/claude-skills-collection/main/install.ps1) } message-queue-architect -Launch"

🚀 Déjà installé ?

claude "/message-queue-architect"

Ou tapez /message-queue-architect dans une session Claude Code, ou décrivez simplement votre besoin — le skill se déclenche automatiquement via le skill-router.

🔑 Déclencheurs automatiques

Le skill s'active automatiquement quand votre demande contient :

message queueRabbitMQKafkaqueuemessagingasyncpub/subbrokerconsumerproducer

📦 Installation manuelle

git clone https://github.com/khalilbenaz/claude-skills-collection.git cp -r claude-skills-collection/dev-skills/message-queue-architect ~/.claude/skills/

Source : dev-skills/message-queue-architect

đź“– Manuel

Message Queue Architect

Workflow

  1. Analyse du besoin : Déterminer le pattern adapté — point-to-point (une tâche, un worker), pub/sub (un événement, N abonnés), event streaming (log immuable, replay possible), ou request/reply (RPC asynchrone) ; estimer le volume, la latence attendue et la durabilité requise.
  2. Choix du broker : RabbitMQ pour le routing complexe (exchanges topic/direct/fanout, bindings flexibles, RPC natif) ; Kafka pour l'event streaming haute performance (retention longue, replay, consumer groups indépendants) ; Azure Service Bus pour l'intégration cloud-native (sessions, dead letter automatique, topics avec filtres) ; NATS pour la latence ultra-faible.
  3. Design des exchanges/topics et queues : Nommer les exchanges/topics de façon explicite (orders.created, payments.v1.processed) ; définir les partitions Kafka en fonction de la clé de partition (garantie d'ordre par clé) ; configurer les bindings et routing keys RabbitMQ ; estimer la retention et la taille des partitions.
  4. Pattern de message : Adopter un envelope standard (messageId, correlationId, timestamp, type, version, source, payload) ; distinguer les commands (intention d'action, un seul handler), les events (fait passé, N handlers), et les documents (transfert de données) ; versionner les contrats de message.
  5. Garanties de livraison : At-most-once (fire & forget, perte possible) pour les métriques non critiques ; at-least-once (acknowledgement, idempotence obligatoire côté consumer) pour la majorité des cas ; exactly-once via Outbox Pattern (transaction DB + publication atomique) pour les cas critiques.
  6. Gestion des erreurs : Configurer la dead letter queue (DLQ) avec TTL et max retries ; implémenter le retry avec backoff exponentiel (ex. 1s, 5s, 30s, 5min) ; détecter les poison messages (erreurs permanentes) et les router vers une queue d'inspection manuelle ; alerter sur la profondeur de la DLQ.
  7. Sérialisation : JSON pour la lisibilité et la simplicité (débug facile) ; Protobuf ou Avro pour la performance et la validation de schéma (schema registry Confluent pour Kafka) ; toujours inclure la version du schéma dans l'envelope pour la compatibilité ascendante/descendante.
  8. Monitoring : Surveiller le consumer lag (indicateur clé de la santé du système), la profondeur des queues, le throughput de messages, le taux d'erreur et la latence end-to-end ; configurer des alertes sur le lag anormal et la DLQ ; utiliser Prometheus + Grafana, Datadog, ou les métriques natives du broker.

Règles