Architecture Event-Driven : Patterns et Compromis
#architecture#event-driven#kafka#messaging
L'architecture event-driven (EDA) découple les producteurs des consommateurs, permettant des systèmes plus scalables, résilients et adaptables au changement. Mais l'EDA introduit sa propre complexité -- consistance éventuelle, défis d'ordonnancement et difficulté de debugging.
Patterns principaux
Pub/Sub (Publish-Subscribe)
Les producteurs publient des événements sur un topic ; plusieurs consommateurs s'abonnent indépendamment.
- Couplage faible entre services
- Facile d'ajouter de nouveaux consommateurs sans modifier les producteurs
- Pas de garantie d'ordre de traitement entre consommateurs
Event Sourcing
Au lieu de stocker l'état courant, stocker la séquence d'événements qui y a mené.
- Piste d'audit complète par conception
- Capacité à reconstruire l'état à n'importe quel point dans le temps
- Permet les requêtes temporelles ("quel était l'état au 1er mars ?")
- Compromis : les modèles de lecture doivent être projetés, le stockage croît
CQRS (Command Query Responsibility Segregation)
Séparer le modèle d'écriture (commandes) du modèle de lecture (requêtes).
- Modèle d'écriture optimisé pour la consistance et la validation
- Modèle de lecture optimisé pour la performance des requêtes
- Souvent combiné avec l'event sourcing
- Compromis : deux modèles à maintenir, consistance éventuelle entre eux
Comparaison des message brokers
| Broker | Modèle | Débit | Ordonnancement | Rétention | Idéal pour |
|---|---|---|---|---|---|
| Apache Kafka | Log distribué | Très élevé | Par partition | Jours à indéfini | Stream processing, event sourcing |
| RabbitMQ | File de messages | Élevé | Par file | Jusqu'à consommation | Files de tâches, patterns RPC |
| AWS SNS/SQS | Pub/Sub + File | Élevé | FIFO optionnel | 14 jours (SQS) | Routage d'événements AWS-native |
| GCP Pub/Sub | Pub/Sub | Élevé | Par clé (ordering) | 31 jours | Pipelines d'événements GCP-native |
| Redis Streams | Log append-only | Très élevé | Par stream | Configurable | Faible latence, cas simples |
Garanties de livraison
| Garantie | Description | Complexité | Cas d'usage |
|---|---|---|---|
| At-most-once | Fire and forget, peut perdre des messages | Faible | Métriques, logs non critiques |
| At-least-once | Retry jusqu'à acquittement, peut dupliquer | Moyen | La plupart des événements métier |
| Exactly-once | Chaque message traité exactement une fois | Élevé | Transactions financières |
L'exactly-once est souvent atteint par des consommateurs idempotents plutôt que par une livraison véritablement exactly-once. Concevez les consommateurs pour gérer les doublons en toute sécurité.
Évolution des schémas d'événements
- Registre de schémas (Confluent, AWS Glue) -- gestion centralisée avec vérification de compatibilité
- Compatibilité ascendante -- les nouveaux consommateurs lisent les anciens événements
- Compatibilité descendante -- les anciens consommateurs lisent les nouveaux événements
- Événements versionnés -- inclure un champ version, les consommateurs gèrent plusieurs versions
- Upcasting -- transformer les anciens événements au nouveau format à la lecture
Pièges courants
- Tempêtes d'événements -- des événements en cascade surchargent le système ; utiliser des circuit breakers
- Hypothèses d'ordonnancement -- les systèmes distribués ne garantissent pas l'ordre global
- Événements fantômes -- événements référençant des données qui n'existent plus
- Enfer du debugging -- tracer une requête à travers 10 services nécessite des IDs de corrélation