---
name: event-driven-architect
description: Conception d'architectures événementielles avec messaging et event sourcing. Se déclenche avec "event driven", "événementiel", "RabbitMQ", "Kafka", "event sourcing", "CQRS", "message broker", "pub/sub", "async messaging".
---

# Event-Driven Architect

## Workflow
1. Identification des événements métier (domain events, integration events) — modéliser les faits immuables qui se sont produits dans le domaine, nommés au passé (OrderPlaced, PaymentProcessed)
2. Choix du broker (RabbitMQ, Kafka, Azure Service Bus, Redis Streams) avec justification — évaluer les besoins de débit, de rétention, d'ordering et de rejeu avant de choisir
3. Design des topics/queues et routing (exchanges, partitions, consumer groups) — définir la topologie de messages selon les patterns de consommation et les exigences de scalabilité
4. Implémentation du pattern choisi (pub/sub, saga, event sourcing, CQRS) — fournir le code complet des producteurs, consommateurs et handlers dans le langage de l'utilisateur
5. Gestion de l'idempotence et du ordering (deduplication, exactly-once, outbox pattern) — chaque consommateur doit gérer les doublons ; l'outbox pattern garantit la cohérence avec la base de données
6. Error handling (dead letter queue, retry policies, poison messages) — définir les stratégies de retry exponentielles, les DLQ et les alertes sur les messages empoisonnés
7. Monitoring et observabilité des flux (message lag, consumer health, tracing) — instrumenter les producers et consumers avec correlation IDs et métriques de lag pour détecter les blocages
8. Schema evolution et versioning des événements — adopter une stratégie de compatibilité (forward/backward) et un schema registry pour éviter les ruptures de contrat

## Règles
- Adapte l'implémentation au stack de l'utilisateur (.NET, Node, Python, Java, Go...) avec des exemples de code concrets utilisant les bibliothèques adaptées à son broker
- Privilégie la simplicité : une architecture événementielle ajoute de la complexité opérationnelle ; ne l'adopter que si les bénéfices (découplage, scalabilité, auditabilité) le justifient
- Fournis toujours des exemples de code pour les patterns critiques (outbox, saga, consumer idempotent)
- Justifie chaque choix technique (broker, pattern) avec ses trade-offs (latence, cohérence éventuelle, complexité)