Systèmes event-driven avec Kafka : cohérence des données et flux asynchrones
Patterns de production pour l’architecture event-driven. Cas d’usage Kafka, cohérence des données et communication inter-services scalable. Appliqué à des plateformes automobiles à l’échelle.
L’architecture event-driven est un modèle où les services communiquent en publiant et en consommant des événements plutôt qu’en s’appelant directement. Apache Kafka est le journal durable et ordonné qui transporte ces événements, ce qui permet à chaque service de monter en charge, de tomber et d’être déployé indépendamment des autres.
Cas d’usage Kafka
Synchronisation stock entre systèmes partenaires. Events campagnes pour suivi budget et attribution leads. Déclencheurs workflows CRM. Pipelines d’audit et d’analytics.
Messagerie haut débit et tolérante aux pannes. Services découplés qui scalent indépendamment.
Cohérence des données
Sémantique exactly-once quand critique. Consumers idempotents pour les retries. Event sourcing pour l’audit. Patterns Saga pour les transactions distribuées.
Schema registry pour l’évolution des contrats. Dead letter queues pour les messages en échec.
Flux asynchrones
Traitement non bloquant pour les tâches longues. Tableaux de bord temps réel alimentés par les streams. Jobs en arrière-plan pour reporting et agrégation.
See Plateforme digitale automobile pour une mise en œuvre concrète.
Questions fréquentes sur les systèmes event-driven
Quand utiliser Kafka plutôt qu’un appel REST ?
- Quand plusieurs services s’intéressent au même changement, quand le producteur ne doit pas attendre le consommateur, ou quand l’événement devra être rejoué plus tard. Un appel REST direct reste plus simple et préférable lorsqu’un seul service attend une réponse immédiate.
Comment garder les données cohérentes entre services event-driven ?
- Des consommateurs idempotents, pour qu’une reprise n’applique jamais deux fois le même changement. La sémantique exactly-once là où un doublon coûterait cher. Le pattern saga pour les transactions réparties. L’event sourcing conserve la piste d’audit, et un schema registry empêche producteurs et consommateurs de diverger.
Que se passe-t-il quand un consommateur échoue à traiter un message ?
- Il réessaie, et un message qui échoue systématiquement part dans une dead letter queue au lieu de bloquer la partition derrière lui. Un message empoisonné devient ainsi quelque chose qu’on peut inspecter et rejouer, plutôt qu’un pipeline à l’arrêt que personne ne remarque avant que les données ne soient périmées.
Kafka remplace-t-il une base de données ?
- Non. Kafka est un journal durable de ce qui s’est passé, pas un magasin qu’on interroge par clé. Chaque service garde sa propre base et se synchronise via le journal. L’event sourcing permet de reconstruire l’état, mais les lectures passent toujours par une projection.