---
name: message-queue-architect
description: Architecture de messaging avec RabbitMQ, Kafka, Azure Service Bus. Se déclenche avec "message queue", "RabbitMQ", "Kafka", "queue", "messaging", "async", "pub/sub", "broker", "consumer", "producer".
---

# 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
- Fournis des exemples de code concrets (configuration broker, producer, consumer) dans le langage/framework de l'utilisateur
- Adapte les recommandations au cloud cible (Azure Service Bus vs Kafka managé vs RabbitMQ on-prem)
- Toujours mentionner les trade-offs (ex. exactly-once = complexité + perf dégradée vs at-least-once + idempotence)
- Commence par la solution simple avant la complexe (une queue simple avant les exchanges topic)
- Insiste sur l'idempotence des consumers : incontournable en at-least-once