Quand devriez-vous envisager d’adopter Apache Kafka ?

Apache Kafka est une plateforme distribuée de streaming d’événements à envisager lorsque plusieurs systèmes doivent consommer les mêmes événements de manière indépendante et que l’historique des événements doit être conservé pendant un certain temps afin de pouvoir être relu ultérieurement. Plutôt que de le choisir simplement parce qu’un traitement asynchrone est nécessaire, il est préférable d’évaluer si vous avez besoin simultanément de plusieurs abonnements, de traitement à haut volume, de retraitement et de tolérance aux pannes. kafka.apache.org↗

Kafka est souvent décrit comme une « file de messages », mais cette seule étiquette n’explique pas pleinement sa valeur fondamentale. Il excelle à enregistrer sous forme d’événements les faits qui se sont produits dans un système — par exemple la création d’une commande, la finalisation d’un paiement, une action client ou un journal système — puis à permettre à plusieurs applications et systèmes de données de les lire à leur propre rythme. À l’inverse, si un petit service doit uniquement traiter une fois un type de tâche d’arrière-plan, la complexité opérationnelle de Kafka peut l’emporter sur ses avantages.

Cet article définit d’abord les problèmes que Kafka résout, puis examine les signaux qui augmentent la valeur de son adoption ainsi que les compromis liés à sa conception et à son exploitation.

Quel type de plateforme est Kafka ?

Kafka s’articule autour de topics qui enregistrent des événements. Un événement est un enregistrement de données représentant un fait survenu dans un système, tel que « une commande a été créée », « un utilisateur a consulté un produit » ou « la température d’un capteur a été mesurée ». Les applications qui écrivent les événements sont appelées producteurs, tandis que celles qui les lisent et les traitent sont appelées consommateurs. kafka.apache.org↗

Les producteurs publient des événements dans des topics, et les consommateurs s’abonnent aux topics dont ils ont besoin et les lisent. Les producteurs n’ont pas besoin de savoir directement qui lit leurs événements. Même si un service d’analyse, de notification ou d’indexation de recherche est ajouté ultérieurement, le service de commandes peut, en principe, publier le même événement de commande sans devoir ajouter continuellement du code d’intégration distinct pour chaque système. Il s’agit d’un couplage faible entre producteurs et consommateurs. kafka.apache.org↗

De plus, les événements Kafka ne disparaissent pas immédiatement après leur lecture par un consommateur. Ils sont stockés conformément aux politiques de rétention définies au niveau des topics, tandis que les consommateurs gèrent des positions indiquant jusqu’où ils ont lu. Il devient ainsi possible pour un nouveau consommateur de lire les enregistrements historiques ou pour un consommateur existant de retraiter depuis un point donné après la correction d’un bug. kafka.apache.org↗

Il est donc plus utile de comprendre Kafka comme une plateforme qui « maintient un historique d’événements partageable » plutôt que comme un système qui se contente de « livrer des messages ». La rétention ne signifie toutefois pas que les données sont conservées indéfiniment. La durée de rétention effective doit être déterminée en fonction des politiques des topics et de la planification de la capacité de stockage.

Comment les composants principaux fonctionnent-ils ensemble ?

Distinguer les principaux composants de Kafka facilite les décisions d’adoption et l’analyse des incidents.

Un topic est divisé en une ou plusieurs partitions. Une partition est un journal d’événements ordonné, et Kafka utilise plusieurs partitions pour paralléliser les lectures et les écritures. Par conséquent, le nombre de partitions n’est pas une simple valeur de configuration ; c’est une décision de conception qui reflète conjointement le débit visé, le parallélisme des consommateurs et les exigences d’ordre. kafka.apache.org↗

Un groupe de consommateurs est un ensemble d’instances de consommateurs exécutant la même tâche. Par exemple, si plusieurs instances de consommateurs chargent des événements de commande dans un entrepôt de données, elles peuvent former un groupe. Au sein du groupe, chaque partition peut être attribuée à un consommateur afin de répartir la charge de traitement. À l’inverse, un service de notification et un service d’analyse appartiennent à des groupes différents ; chacun peut donc lire indépendamment les mêmes événements de commande. kafka.apache.org↗

Cette structure est favorable à la montée en charge, mais avoir davantage de consommateurs actifs dans un groupe que de partitions ne signifie pas qu’ils pourront tous traiter davantage de partitions simultanément. Vous ne devez pas vous attendre à ce que le parallélisme augmente sans limite simplement en multipliant les instances. Dès le départ, la planification des partitions doit tenir compte à la fois de la distribution réelle des clés et des besoins futurs de montée en charge.

Quels problèmes font de Kafka un choix plus pertinent ?

Le signal d’adoption le plus fort est une situation dans laquelle plusieurs systèmes doivent consommer un même événement à des fins différentes et à des vitesses différentes. Ce qui importe n’est pas le nombre de consommateurs en soi, mais la nécessité pour les consommateurs d’évoluer indépendamment du producteur.

Prenez le cas d’un système de commerce électronique dans lequel une commande est créée. Au départ, il peut suffire de mettre à jour la base de données des commandes. Plus tard, la réservation du stock, les flux de paiement, les notifications clients, la détection de fraude, les mises à jour des données de recherche et de recommandation, ainsi que le chargement analytique peuvent être ajoutés. Si chaque capacité reste reliée au service de commandes par des appels synchrones, la latence ou la défaillance d’une fonction peut affecter le parcours de traitement des commandes, et les relations d’intégration peuvent devenir complexes.

Dans ce cas, le service de commandes peut publier un événement order created, tandis que chaque système en aval lit les événements dont il a besoin au moyen d’un groupe de consommateurs distinct. La possibilité d’ajouter de nouveaux consommateurs sans modifier directement le producteur existant est un cas d’usage clé de Kafka. kafka.apache.org↗

Les situations suivantes méritent tout particulièrement d’être évaluées :

• Des événements centraux, comme les changements de statut de commande, de paiement ou d’adhésion, sont consultés par plusieurs systèmes métier.
• Des données telles que les clics utilisateurs, les pages vues, les journaux opérationnels ou les mesures s’accumulent en continu.
• L’analyse, les notifications, l’indexation et le chargement dans l’entrepôt de données nécessitent tous les mêmes événements sources.
• Le flux de production doit continuer, même lorsque les consommateurs ont des vitesses de traitement et des points de reprise différents après des défaillances.
• Lorsqu’un nouveau cas d’usage apparaît, connecter directement le service source à chaque système en aval est coûteux.

L’une de ces conditions à elle seule ne signifie pas nécessairement que Kafka est requis. Mais si plusieurs s’appliquent simultanément et que chaque flux de données est susceptible de croître, une architecture de streaming d’événements peut apporter davantage d’avantages que de simples intégrations point à point.

Comment Kafka absorbe-t-il les volumes élevés et les fortes variations ?

Kafka est conçu pour répartir les lectures et les écritures d’événements au moyen de partitions ; il peut donc être utilisé pour des flux de données qui génèrent continuellement un grand nombre d’événements. Parmi les exemples courants figurent l’agrégation de logs, le suivi de l’activité utilisateur, les métriques de supervision, les mesures IoT et les événements de transaction. kafka.apache.org↗

Le rôle de Kafka consiste ici à relâcher le couplage qui exige que les vitesses de production et de consommation correspondent en permanence. Par exemple, si les événements connaissent un pic pendant une période donnée, les consommateurs peuvent ne pas être en mesure de tous les traiter immédiatement. Si les événements sont conservés, les consommateurs peuvent rattraper le retard accumulé. Cela leur donne la possibilité d’ajuster indépendamment leur cadence de traitement sans bloquer les producteurs.

Cela ne signifie pas que le retard disparaît. Cela signifie plutôt que le retard peut être géré comme un arriéré accumulé d’événements enregistrés. Le retard du consommateur est une métrique opérationnelle qui indique à quelle distance un consommateur se situe des événements les plus récents. Si ce retard continue d’augmenter, il convient d’examiner les performances des consommateurs, les dépendances externes, la distribution des partitions et les nouvelles tentatives après erreur. Kafka fournit des métriques de supervision basées sur JMX, et les environnements de production doivent également prendre en compte la sécurité des chemins d’accès à la supervision. kafka.apache.org↗

Lors de l’évaluation des besoins de débit, il est préférable de distinguer les questions suivantes plutôt que d’affirmer vaguement que « le trafic est élevé » :

1. Combien d’événements se produisent par seconde ou durant chaque période ?
2. Quelles sont les tailles moyenne et maximale d’un événement individuel ?
3. Combien de temps durent les pics ?
4. Quel retard des consommateurs est acceptable ?
5. À quelle vitesse l’arriéré doit-il être traité après une interruption ?
6. Pendant combien de temps les événements doivent-ils être conservés ?

Les réponses à ces questions révèlent que le nombre de partitions, la capacité de stockage, la réplication, la montée en charge des consommateurs et le temps de retraitement sont des préoccupations liées. Kafka fournit une base pour un débit élevé, mais les performances et les coûts réels varient selon la taille des événements, le déséquilibre des clés, les politiques de rétention et les goulots d’étranglement dans la logique des consommateurs.

Pourquoi le retraitement est-il une raison importante d’adopter Kafka ?

Le traitement en temps réel produit un résultat immédiatement après l’arrivée d’un événement. Il peut par exemple mettre à jour le stock après une commande, détecter les transactions répondant à certaines conditions ou agréger des métriques à la minute. Cependant, le retraitement de données historiques peut être une exigence aussi importante que le traitement en temps réel.

Le retraitement est nécessaire pour de nombreuses raisons. Après la correction d’un bug dans le code d’un consommateur, vous pouvez recréer des résultats manquants ou calculés de manière incorrecte. Lorsque de nouvelles règles d’analyse sont introduites, vous pouvez créer des données dérivées à partir de l’historique d’événements existant. Si la consommation s’arrête à cause d’une défaillance, vous pouvez effectuer une reprise en relisant depuis la dernière position traitée. Dans Kafka, les événements ne sont pas supprimés immédiatement après leur consommation et peuvent être relus dans les limites de la politique de rétention. kafka.apache.org↗

Par exemple, supposons que les événements de comportement client aient d’abord été utilisés uniquement pour agréger le nombre quotidien de visiteurs. Si une analyse des conversions par canal d’acquisition devient nécessaire ultérieurement, un groupe de consommateurs distinct peut lire les événements historiques et générer de nouveaux résultats analytiques, à condition que les champs requis soient inclus dans les événements et que la période de rétention soit toujours active. Ce travail peut être isolé sans interrompre le consommateur d’agrégation existant ni exécuter des requêtes de grande ampleur sur la base de données du service source.

Toutefois, la capacité de retraiter ne résout pas à elle seule les problèmes de qualité des données. Si les événements ne contiennent pas les identifiants requis, les horodatages de survenue ou les informations de version, ou si la signification du schéma a changé sans gestion de compatibilité, il est difficile de produire des résultats fiables même lorsque les données historiques peuvent être relues. De plus, une exigence de retraitement de données antérieures à la période de rétention ne peut pas être satisfaite par les seuls topics Kafka. Par conséquent, si le retraitement est une raison d’adoption, déterminez d’abord « ce qui sera rejoué, pendant combien de temps et avec quelle signification ».

Kafka peut-il également connecter des bases de données et des systèmes externes ?

Kafka peut être utilisé non seulement pour transmettre des événements entre services, mais aussi comme flux central pour des pipelines de données. La capture des changements de données (CDC) est une approche qui envoie dans un flux de données les changements survenus dans une base de données ; elle peut être envisagée lorsque les modifications de données opérationnelles doivent être répercutées dans l’analyse, la recherche ou d’autres services. Kafka Connect fournit une API et un modèle de connecteurs pour les intégrations récurrentes d’entrée et de sortie de données avec des systèmes externes. kafka.apache.org↗

Voici des exemples où cette configuration peut être utile :

• Envoyer continuellement les changements d’une base de données opérationnelle vers un magasin analytique.
• Collecter les logs et métriques de plusieurs applications dans un flux partagé.
• Répercuter des données générées dans un système dans un index ou une table dérivée d’un autre magasin.
• Construire des flux de données continus entre des environnements sur site et cloud.

L’utilisation de connecteurs n’élimine pas les différences entre les modèles de données, la sémantique des suppressions, les problèmes d’ordre, la gestion des accès ou les limites d’écriture des systèmes cibles. En particulier, lorsque des changements de base de données sont utilisés comme événements, vous devez distinguer le fait qu’« une ligne a changé » de l’événement métier selon lequel « une commande a été confirmée ». Le premier est plus proche d’un changement de stockage, tandis que le second est un événement métier porteur d’une signification de domaine. Les traiter comme identiques peut amener les consommateurs à dépendre trop fortement de la structure de stockage.

Par conséquent, l’adoption de Kafka pour des pipelines de données est plus fiable lorsqu’elle ne se contente pas de réduire le nombre de connexions, mais clarifie aussi les propriétaires des données, les schémas et la responsabilité des changements.

Dans quelle mesure l’ordre est-il garanti, et pourquoi la conception des clés importe-t-elle ?

Dans Kafka, l’ordre des événements est garanti au sein d’une partition, et non dans l’ensemble d’un topic. Les partitions multiples permettent le traitement parallèle, mais aucun ordre global unique n’existe entre elles. kafka.apache.org↗

Par exemple, si le statut d’une commande doit être traité dans la séquence created, payment completed et shipping started, vous pouvez utiliser l’identifiant de commande comme clé afin que les événements de la même commande soient enregistrés dans la même partition. Vous pouvez ainsi utiliser l’ordre des enregistrements de cette commande comme unité. Les changements de statut client peuvent être conçus de façon similaire en utilisant l’identifiant client comme clé.

À l’inverse, si tous les événements de commande doivent être traités un par un selon un ordre chronologique global, un choix proche d’une partition unique peut être effectivement requis. Dans ce cas, l’ordre peut devenir plus simple, mais la capacité de traitement parallèle est limitée. L’ordre global et un parallélisme élevé ne sont pas des propriétés que vous pouvez obtenir conjointement sans limite.

Le choix des clés pose un autre problème. Si un client ou un appareil particulier génère un nombre anormalement élevé d’événements, cette clé peut se concentrer dans une seule partition. Cela peut être considéré comme un déséquilibre des clés, et seuls certains consommateurs peuvent devenir excessivement sollicités. Les clés doivent donc représenter l’unité métier qui exige un ordre, tout en étant évaluées pour vérifier qu’elles ne créent pas de déséquilibre excessif dans la distribution de données attendue.

Lors de la documentation des exigences d’ordre, ne vous arrêtez pas à dire que « l’ordre est important ». Il est préférable de les préciser comme suit :

• Dans quel périmètre d’identifiant l’ordre est-il requis ?
• Un ordre selon le temps de l’événement ou selon l’écriture de l’enregistrement est-il requis ?
• Comment les événements arrivant tardivement seront-ils traités ?
• Quelle erreur métier se produit lorsque les événements sont désordonnés ?
• Un ordre global est-il nécessaire, même au prix d’un parallélisme réduit ?

Les réponses déterminent la séparation des topics, les clés, le nombre de partitions et la logique des consommateurs.

Comment comprendre le traitement des doublons et le traitement exactement une fois ?

Les consommateurs Kafka nécessitent des conceptions qui supposent par défaut un traitement au moins une fois, compte tenu des défaillances et des nouvelles tentatives. Par exemple, si un consommateur termine le traitement d’un événement mais s’arrête avant d’enregistrer sa position de traitement, il peut relire le même événement après reprise. Le traitement dupliqué d’un même événement est donc possible. kafka.apache.org↗

La solution pratique consiste à rendre la logique du consommateur idempotente. L’idempotence est la propriété qui permet de produire le même résultat final même lorsqu’une même opération est effectuée plusieurs fois. Par exemple, une opération telle que set the status of order 123 to delivered peut être conçue de manière à ce que la répétition de la même mise à jour de statut ne modifie pas matériellement le résultat. À l’inverse, une opération qui unconditionally adds 1,000 points peut produire un résultat différent si elle reçoit deux fois le même événement ; elle requiert donc une stratégie de déduplication, telle que l’enregistrement des identifiants d’événements ou l’utilisation de contraintes d’unicité dans le magasin cible.

Lorsqu’elles relient lectures, traitements et écritures au sein des topics Kafka, les configurations de traitement exactement une fois sont prises en charge par Kafka grâce aux transactions et au niveau d’isolation read_committed. Il ne faut toutefois pas comprendre cela comme signifiant que chaque effet externe se produit automatiquement une seule fois. Les effets de bord en dehors de Kafka, tels que les mises à jour de bases de données externes, l’envoi d’e-mails ou les appels à des API de paiement, nécessitent une coordination avec le système cible et une conception distincte. kafka.apache.org↗

Par conséquent, avant l’adoption, posez les questions suivantes pour chaque consommateur :

• Que se passe-t-il si le même événement est traité deux fois ?
• Chaque événement possède-t-il un identifiant utilisable pour détecter les doublons ?
• Le magasin de résultats empêche-t-il les doublons ou prend-il en charge des mises à jour sûres ?
• Quels sont les critères de nouvelle tentative lorsqu’un appel externe échoue ou que sa réponse est ambiguë ?
• Comment les effets de bord déjà réalisés seront-ils traités lors du retraitement ?

Si Kafka est adopté sans répondre à ces questions, le transport lui-même peut être fiable tandis que les résultats métier dupliqués ou incohérents restent difficiles à détecter.

La tolérance aux pannes et la durabilité sont-elles garanties automatiquement ?

Kafka peut être configuré pour se préparer aux défaillances de brokers en répliquant les partitions des topics. Cela peut constituer un avantage majeur pour les flux de données où les partitions répliquées, la continuité d’exploitation durant les défaillances de brokers et la répartition de charge entre de nombreux consommateurs sont importantes. kafka.apache.org↗

Toutefois, conclure que « les données ne peuvent jamais être perdues parce que nous utilisons Kafka » est incorrect. La durabilité et la disponibilité réelles dépendent du facteur de réplication, des paramètres d’accusé de réception des producteurs, de l’étendue des défaillances pouvant survenir simultanément, des politiques de rétention et des procédures d’exploitation. Même avec des réplicas, les résultats peuvent différer des attentes si les réplicas sont placés dans le même domaine de défaillance, si des paramètres importants n’atteignent pas le niveau requis ou si les procédures de reprise n’ont pas été validées par les opérateurs. kafka.apache.org↗

Il est utile de formuler explicitement les exigences de tolérance aux pannes. Par exemple : « La production et la consommation des événements de commande doivent continuer si un broker tombe en panne », « Les doublons sont acceptables après une défaillance de consommateur, mais pas les omissions » ou « Les événements d’une période spécifiée doivent pouvoir être retraités ». Ces exigences déterminent non seulement la réplication et les accusés de réception, mais aussi l’idempotence des consommateurs, la supervision, la capacité de stockage et les exercices de reprise.

Comme l’historique retraitable peut devenir un actif de données important, vous devez évaluer séparément si les topics contiennent des informations personnelles ou des données métier sensibles. Le contrôle d’accès et la sécurité des interfaces opérationnelles ne sont pas des tâches a posteriori distinctes de la conception des flux de données. L’exploitation de Kafka requiert également des paramètres de sécurité pour l’accès administratif, y compris pour la supervision. kafka.apache.org↗

Kafka est-il toujours meilleur qu’une simple file de travaux ou qu’une API synchrone ?

Non. Kafka n’est pas un remplacement automatique pour chaque besoin asynchrone. Si le besoin s’apparente davantage à « convertir une image une fois », « générer un rapport et ne renvoyer que le résultat » ou « faire prendre et traiter une tâche par un seul consommateur », et que la rétention longue, les abonnements multiples et le retraitement ne sont pas essentiels, une file de travaux plus simple ou un service managé peut mieux convenir en termes de coût et de charge opérationnelle. Les principales forces de Kafka émergent lorsque sont combinés des flux d’événements à grande échelle, plusieurs consommateurs indépendants et la réutilisation d’un historique conservé. kafka.apache.org↗

Les API synchrones jouent également un rôle différent. Une requête où un utilisateur clique sur un bouton et a besoin d’un résultat immédiat de succès ou d’échec relève naturellement d’une API requête-réponse. Une fois cette requête terminée, le flux qui informe les systèmes en aval de ce fait peut être séparé sous forme d’événements. En d’autres termes, plutôt que de choisir uniquement entre appels synchrones et Kafka, il est souvent plus approprié d’utiliser les API pour les interactions utilisateur et les événements pour la diffusion asynchrone vers les systèmes en aval.

La comparaison suivante peut simplifier la décision :

Ce tableau n’est pas une règle absolue de sélection de produit. La plateforme existante d’une équipe, la disponibilité de services managés, les politiques de sécurité et les effectifs d’exploitation influencent également la décision. L’élément déterminant est la nature du flux de données que vous cherchez à résoudre, plutôt qu’une liste de fonctionnalités.

Que faut-il préparer pour l’exploitation et la gouvernance ?

L’adoption de Kafka ne se limite pas à l’ajout d’une bibliothèque applicative. Elle exige aussi un modèle d’exploitation permettant de gérer continuellement les topics, partitions, réplications, rétentions, autorisations d’accès, supervision et capacités. Kafka fournit des métriques JMX, mais les informations opérationnelles ne créent une réelle valeur que lorsque vous déterminez quelles métriques déclenchent des alertes, qui intervient et comment la reprise est effectuée. kafka.apache.org↗

Premièrement, les contrats d’événements doivent être gérés. Un contrat d’événement inclut non seulement les noms de champs et les types de données, mais aussi la signification métier de chaque champ, son caractère facultatif, la façon dont les changements de version sont traités et la distinction entre l’heure de production et l’heure de survenue. Des normes de compatibilité sont nécessaires afin que les consommateurs ne fonctionnent pas incorrectement sans le savoir lorsqu’un producteur supprime un champ ou en modifie la signification.

Ensuite, les politiques de topics doivent être claires. Pour chaque topic, vous devez décider des éléments suivants :

• Quels événements il contient et qui en est responsable.
• Quels sont la période de rétention et les critères de capacité de stockage.
• Quelles exigences d’ordre et de débit ont déterminé le nombre de partitions et la clé.
• Quel niveau de défaillance la réplication et les accusés de réception des producteurs visent à couvrir.
• Qui peut produire et consommer, et comment les données sensibles sont protégées.
• À quel niveau de retard des consommateurs l’investigation et la réponse commencent.

La planification de capacité est également importante. Des périodes de rétention plus longues ou une réplication accrue augmentent les besoins de stockage. Si les consommateurs doivent pouvoir retraiter après un arrêt prolongé, l’historique devra peut-être être conservé en conséquence. À l’inverse, une rétention courte peut réduire les coûts, mais limite l’étendue des données historiques disponibles pour la reprise après incident ou l’ajout de nouveaux consommateurs. Ce choix définit non seulement les coûts, mais aussi l’étendue des capacités produit et de la récupérabilité.

Dans les organisations où les responsabilités opérationnelles ne sont pas claires, une plateforme Kafka partagée peut au contraire accroître les problèmes de dépendance. S’accorder sur les changements et incidents qui relèvent des responsables de topics, des opérateurs de plateforme, des responsables de sécurité et des équipes de développement des consommateurs est aussi important que la configuration technique.

Quelles questions utiliser pour décider avant l’adoption ?

La question qui permet le mieux de déterminer s’il faut adopter Kafka n’est pas « Avons-nous besoin de messages asynchrones ? ». Une question plus précise est : Plusieurs consommateurs indépendants doivent-ils lire continuellement un historique d’événements à grande échelle et le retraiter après un retard ou une défaillance ? Si la réponse est clairement oui, vos exigences sont probablement alignées sur les caractéristiques fondamentales de Kafka. kafka.apache.org↗kafka.apache.org↗

Vous pouvez utiliser la liste de contrôle suivante pour commencer les discussions sur l’adoption :

1. Consommateurs multiples : plusieurs systèmes doivent-ils actuellement, ou dans un avenir proche, utiliser le même événement indépendamment ?
2. Valeur de l’historique : les événements doivent-ils être conservés après leur consommation et relus pour corriger des bugs, réaliser des audits ou produire de nouvelles analyses ?
3. Échelle de traitement : une ingestion soutenue à haut volume ou des pics de trafic exigent-ils de découpler la production de la consommation ?
4. Périmètre d’ordre : le problème peut-il être résolu par un ordre selon une clé telle qu’un client ou une commande, plutôt que par un ordre global ?
5. Gestion des doublons : chaque consommateur peut-il traiter ou identifier les événements dupliqués en toute sécurité ?
6. Gestion des contrats : existe-t-il des responsables et des processus pour gérer les changements de schémas et de significations des événements ?
7. Préparation opérationnelle : un responsable peut-il observer et traiter le retard, la capacité de stockage, les défaillances de brokers, les autorisations et le retraitement ?
8. Comparaison des alternatives : le besoin pourrait-il être satisfait plus simplement par une distribution de travaux à consommateur unique ou par des requêtes-réponses seules ?

Tous les éléments n’ont pas besoin d’être parfaits dès le départ pour adopter Kafka. Mais si les besoins des points 1 à 5 sont forts alors que la préparation des points 6 et 7 est absente, l’écart peut être important entre la possibilité technique et un système exploitable. Il peut être utile de valider d’abord les contrats d’événements, la gestion des doublons, l’observation du retard et le retraitement dans un flux de données de portée limitée.

Conclusion : Kafka est puissant lorsque l’historique des événements doit être partagé

Apache Kafka n’est pas seulement un outil permettant de déplacer des messages de manière asynchrone ; c’est une plateforme qui conserve des flux d’événements partagés par plusieurs systèmes et leur permet de consommer ces flux indépendamment. Sa valeur d’adoption augmente dans les environnements qui ont simultanément besoin de plusieurs abonnements aux mêmes événements, du traitement parallèle de flux de données à haut volume, du rattrapage après un retard et du retraitement d’enregistrements historiques. kafka.apache.org↗kafka.apache.org↗

À l’inverse, des alternatives plus simples peuvent être mieux adaptées aux exigences qui consistent à confier un travail ponctuel à un seul consommateur, à des requêtes centrées sur des réponses immédiates ou à de petits flux où la charge opérationnelle doit être minimisée. Lorsque vous choisissez Kafka, évaluez non seulement le débit, mais aussi votre capacité à gérer l’ordre au niveau des partitions, le traitement des doublons, les politiques de rétention, les contrats d’événements, la sécurité et l’observabilité. Plus ces conditions sont réunies, plus Kafka peut devenir un socle permettant de réduire le couplage entre les services et d’élargir les usages des données.