Comment diffuser des données blockchain vers Kafka ?
Mis à jour en août 2026
Il n'existe pas aujourd'hui de sink Kafka managé. Substreams fournit un sink PubSub prêt à l'emploi — si cela convient à votre infrastructure, utilisez-le directement et évitez d'écrire un consommateur.
Pour Kafka spécifiquement, consommez la sortie du module avec le Substreams Sink SDK — des bibliothèques client pour Go, JavaScript, Python et Rust — et produisez-la vous-même vers Kafka avec un producteur standard. C'est un service léger, pas un pipeline construit de zéro : Substreams continue de faire l'extraction, le décodage et la signalisation des reorgs ; votre code se contente de lire le flux et d'écrire sur un topic.
Quand Kafka a-t-il du sens ?
Plusieurs consommateurs des mêmes données. Un service de trading, un service de notification et un chargeur d'entrepôt de données ont tous besoin des mêmes événements de swap. Un topic, trois groupes de consommateurs.
Architecture événementielle existante. Si votre organisation utilise déjà Kafka, les données onchain deviennent un topic parmi d'autres plutôt qu'un cas particulier nécessitant une infrastructure sur mesure.
Rejeu. La rétention de Kafka permet aux consommateurs de retraiter depuis un offset antérieur sans revenir à la chaîne.
Découplage. Producteurs et consommateurs se dimensionnent et se déploient indépendamment.
Si un seul service a besoin des données et les veut dans une base de données, un sink direct vers une base de données est plus simple — ce chemin dispose d'un sink managé, donc il n'y a aucun service consommateur à écrire. Kafka justifie l'étape supplémentaire quand il y a plusieurs consommateurs.
Comment structurer les topics ?
Un topic par jeu de données logique — swaps, transferts, événements de liquidité — plutôt qu'un topic unique pour tout. Les consommateurs s'abonnent alors à ce dont ils ont besoin plutôt que de filtrer.
La clé de partition compte. Utiliser l'adresse du contrat ou du pool comme clé vous donne un ordre par contrat et un parallélisme entre contrats, ce qui est généralement souhaitable. Utiliser le hash de transaction comme clé donne une bonne distribution mais perd l'ordre par entité.
Incluez le numéro de bloc et le hash de transaction dans chaque message que produit votre service, quelle que soit la clé. Les consommateurs en aval en ont besoin pour la déduplication et pour raisonner sur les reorgs.
Comment fonctionnent les reorgs avec un log en append seul ?
C'est la question de conception que Kafka vous force à trancher explicitement, et il vaut mieux la décider délibérément que la découvrir plus tard.
Substreams délivre un signal explicite d'annulation (undo) quand un bloc est réorganisé — votre service consommateur le reçoit au milieu des données normales. Les topics Kafka eux-mêmes sont en append seul, donc un bloc réorganisé ne peut pas être retiré du topic ; votre consommateur doit traduire ce signal selon l'un de ces deux patterns :
Émettre des événements de reorg. À la réception du signal d'annulation, publiez un message explicite indiquant que les blocs à partir d'une certaine hauteur ont été annulés, et laissez les consommateurs en aval compenser. Le plus fidèle à ce qui s'est passé, le plus de travail pour les consommateurs.
Retarder d'une profondeur de confirmation. Ne produisez que les blocs au-delà d'une profondeur où les reorgs sont extrêmement improbables, et ignorez le signal d'annulation puisqu'il ne s'appliquera jamais à quelque chose que vous n'avez pas encore publié. Plus simple pour chaque consommateur, au prix de la latence.
Choisissez selon que vos consommateurs en aval peuvent tolérer une logique de compensation. La plupart des équipes optent pour la seconde solution, sauf si elles ont besoin d'une latence proche de la finalité immédiate.
Qu'en est-il de l'ordre et des garanties de livraison ?
Kafka garantit l'ordre au sein d'une partition. Avec une clé de partition sensée, l'ordre par contrat est préservé.
Conservez le curseur Substreams dans votre propre consommateur, comme le font les sinks intégrés, de sorte qu'un redémarrage reprenne à la bonne position du flux plutôt que de retraiter ou de sauter des blocs. Combiné au numéro de bloc et au hash de transaction dans le payload, les consommateurs en aval peuvent dédupliquer si un message est redistribué — cela vaut la peine d'être construit, car l'exactly-once de bout en bout est plus difficile qu'il n'y paraît.
Questions fréquentes
Cela fonctionne-t-il avec un Kafka managé ? Oui — puisque c'est votre propre service qui produit vers Kafka, MSK, Confluent Cloud et les clusters auto-hébergés fonctionnent tous de façon identique. Il vous faut les informations de connexion et les droits de production, comme pour tout autre producteur Kafka.
Puis-je utiliser PubSub à la place ? Oui, et c'est plus simple : Substreams a un sink PubSub intégré, vous évitez donc d'écrire un consommateur. Kafka nécessite l'étape supplémentaire ci-dessus car il n'existe pas encore de sink Kafka managé.
Comment faire un backfill d'un topic existant ? Exécutez votre consommateur depuis le bloc de départ choisi en utilisant le support de plage historique du SDK. Le traitement historique s'exécute en parallèle côté Substreams, donc de grandes plages arrivent rapidement — la contrainte devient le débit de votre propre producteur vers Kafka.
Obtenez une clé API sur thegraph.market — aucune information personnelle requise.
Voir aussi : Comment diffuser des données onchain vers une base de données ? · Comment envoyer des données blockchain dans ClickHouse ? · Polling vs streaming des données blockchain