tadata
← Retour à l'accueil

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
tadata
Write side: commands Read side: queries Checkout API Lambda: placeorder TransactWriteItems:order + outbox item DynamoDB orders single transaction DynamoDB Streams(outbox) commands EventBridge Pipes → bus publish SQS perconsumer buffer, DLQ ProjectorLambda idempotentupsert Read model OpenSearch /DynamoDBview Query API subscribe results replay events Transactional outbox et modèles de lecture CQRS
Write side: commands Read side: queries Checkout API Lambda: placeorder TransactWriteItems:order + outbox item DynamoDB orders single transaction DynamoDB Streams(outbox) commands EventBridge Pipes → bus publish SQS perconsumer buffer, DLQ ProjectorLambda idempotentupsert Read model OpenSearch /DynamoDBview Query API subscribe results replay events Transactional outbox et modèles de lecture CQRS

Extrait de la fiche « SQS and SNS: Messaging Patterns in Depth » · Demander la fiche complète

Comparaison des message brokers

BrokerModèleDébitOrdonnancementRétentionIdéal pour
Apache KafkaLog distribuéTrès élevéPar partitionJours à indéfiniStream processing, event sourcing
RabbitMQFile de messagesÉlevéPar fileJusqu'à consommationFiles de tâches, patterns RPC
AWS SNS/SQSPub/Sub + FileÉlevéFIFO optionnel14 jours (SQS)Routage d'événements AWS-native
GCP Pub/SubPub/SubÉlevéPar clé (ordering)31 joursPipelines d'événements GCP-native
Redis StreamsLog append-onlyTrès élevéPar streamConfigurableFaible latence, cas simples

Garanties de livraison

GarantieDescriptionComplexitéCas d'usage
At-most-onceFire and forget, peut perdre des messagesFaibleMétriques, logs non critiques
At-least-onceRetry jusqu'à acquittement, peut dupliquerMoyenLa plupart des événements métier
Exactly-onceChaque 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é.

tadata
At-most-once At-least-once +idempotent sink Recommended Exactly-once(transactions / 2PC) Data loss on failure possible ✗ ✗ Duplicates on failure ✗ absorbed by upsert ✗ Mechanism commit before processing commit after processing;dedup by key atomic output + offsets Latency cost nothing added low commit interval Typical use metrics you can lose features, predictions,most ML money, counts, labels
At-most-once At-least-once +idempotent sink Recommended Exactly-once(transactions / 2PC) Data loss on failure possible ✗ ✗ Duplicates on failure ✗ absorbed by upsert ✗ Mechanism commit before processing commit after processing;dedup by key atomic output + offsets Latency cost nothing added low commit interval Typical use metrics you can lose features, predictions,most ML money, counts, labels
Les trois garanties côte à côte ; la colonne recommandée est la cible habituelle

Extrait de la fiche « Exactly-Once and Failure Handling » · Demander la fiche complète

É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
tadata
ModeNew schema can readSafe changeDeploy first
BACKWARDdata written with the previous schemadelete a field, add an optional field with a defaultconsumers
FORWARDold schema can read new dataadd a field, delete an optional fieldproducers
FULLboth directionsadd or delete optional fields with defaults onlyeither
*_TRANSITIVEsame, against all earlier versionssame, checked against every version-
NONEno checkanything (breaks consumers silently)-
Modes de compatibilité du schema registry (Confluent Schema Registry et compatibles ; BACKWARD par défaut)

Extrait de la fiche « Event Streams and Kafka » · Demander la fiche complète

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

Ressources

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.