En 2011, LinkedIn a lâché un truc nommé Apache Kafka dans la nature. Quatorze ans plus tard, c'est le système de plumbing le plus adopté du monde data. Mais attention : la majorité des déploiements que je croise en mission l'utilisent comme une simple queue de tâches. C'est à la fois une erreur et une occasion manquée.
Tu veux comprendre pourquoi Kafka redéfinit réellement les standards ? Commençons par un chiffre : chez un acteur du retail, on est passé de 3 000 à 45 000 événements traités par seconde en remplaçant RabbitMQ par Kafka. Ce n'est pas une question de performance brutale, mais d'architecture : le log de Kafka est un journal distribué, répliqué, qui permet de rejouer l'historique. Une file classique, elle, supprime les messages après consommation. Tout est dans cette nuance.
Dans cet article, je vais te montrer concrètement :
- Pourquoi l'architecture de Kafka (topics, partitions, producteurs/consommateurs) en fait le standard de facto de l'event streaming ;
- Comment distinguer un vrai cas d'usage de streaming d'une simple file de tâches ;
- Pourquoi le Schema Registry est indispensable pour faire évoluer tes schémas sans casser tes consommateurs ;
- Comment surveiller la santé de ton infrastructure, notamment le consumer lag.
On parlera aussi des pièges : Kafka n'est pas magique, et si tu ne maitrises pas la partition et le lag, tu vas te brûler. C'est un avis personnel, mais basé sur des années de prod réelle.
Kafka : le socle de l'event streaming moderne
Le point que la plupart des devs zappent : Kafka n'est pas une queue. C'est un log distribué. Chaque message reste dans le topic jusqu'à expiration de la rétention, pas jusqu'à consommation. Tu peux donc reculer l'offset d'un consommateur et rejouer tout l'historique. Essaie ça avec RabbitMQ, tu vas pleurer.
Regarde l'architecture : les topics sont découpés en partitions. Chaque partition est un journal ordonné et immutable. Les messages sont distribués selon la clé, ce qui garantit l'ordre par clé. Chez moi, un producteur Kafka typique ressemble à ça :
Le consommateur, lui, lit avec un groupe.id, et c'est ce groupe qui track l'offset. Voilà pourquoi Kafka est devenu le socle de l'event streaming : tu peux le scaler horizontalement, ajouter des consommateurs, rejouer des événements, et connecter tes pipelines avec Kafka Streams ou KSQL. Ce n'est pas un outil magique – la gestion des partitions et du lag demande de la pratique. Mais une fois que tu as capté le modèle du journal, tu ne reviens plus en arrière.
Kafka en pratique : cas d'usage et limites
Le cas le plus parlant : une plateforme e-commerce qui gérait 5 000 événements/seconde avec RabbitMQ. Après migration vers Kafka, le même cluster a encaissé 45 000 événements/seconde sans sourciller. Et la différence ne se joue pas sur la performance brute. C'est le modèle qui change. Kafka est un log distribué, pas une file. Les messages restent dans le topic pendant la rétention, tu peux reculer l'offset et rejouer tout l'historique. Avec une file classique, dès qu'un consommateur lit, le message est supprimé. Deux philosophies incompatibles.
Les cas où Kafka brille réellement, ce sont les pipelines de données temps réel, la synchronisation d'événements entre microservices, la collecte de logs, l'event sourcing et le stream processing avec Kafka Streams. Chez un client bancaire, j'ai streamé les transactions vers un moteur de fraude : le topic alimentait en parallèle un détecteur de fraude et un entrepôt de données. Chaque consommateur avance à son rythme, sans blocage mutuel. C'est exactement pour ça qu'il est devenu le standard de l'event streaming.
Mais ne te trompe pas d'outil. Kafka n'est pas une queue de tâches. Si tu veux distribuer des jobs à traiter une seule fois avec un suivi de statut, utilise RabbitMQ, Redis ou Celery. J'ai vu des équipes utiliser Kafka pour du task queueing et se noyer dans les rebalances de consumer group et les offsets. Mauvais choix. La vraie question : as-tu besoin de rejouer l'historique ? As-tu plusieurs consommateurs indépendants sur le même flux ? Si oui, vas-y. Sinon, passe ton chemin.
Évoluer les schémas sereinement avec Schema Registry
Tu changes un champ de string à int dans tes événements et paf, tous tes consommateurs explosent en prod. C'est exactement le scénario que le Schema Registry évite. Sans lui, chaque producteur et chaque consommateur vit dans son monde.
L'idée est simple : chaque schéma est versionné, stocké, et testé pour rester compatible avec les versions précédentes. Confluent Schema Registry devient ton garde-fou, il refuse d'enregistrer une version qui casserait les contrats. Regarde un schéma Avro minimal :
La clé, c'est le champ default : ajouter un champ optionnel est rétro-compatible, donc tes consommateurs actuels continuent de lire les anciens messages. Le Schema Registry te donne la règle exacte : BACKWARD, FORWARD, FULL. En prod, je règle toujours BACKWARD pour les sujets critiques, comme ça je peux faire évoluer les producteurs sans arrêter les consommateurs.
Mon avis tranché : si tu ne fais pas ça, tôt ou tard un collègue modifiera un schéma en douce, et toi tu débuggeras des messages illisibles à 3h du matin. Avec Schema Registry, tu rends l'évolution des contrats aussi naturelle qu'un git commit.
Surveiller et opérer Kafka en production
Le premier réflexe, c'est le consumer lag, pas le CPU ni la RAM. Le lag mesure la distance entre l'offset écrit par le producteur et l'offset lu par ton groupe de consommateurs. S'il grimpe, tes consommateurs ne suivent pas, et tes data pipelines prennent du retard sans que personne ne s'en aperçoive.
Concrètement, sur un cluster qui avale 45 000 événements/seconde, je lance kafka-consumer-groups --bootstrap-server localhost:9092 --describe --group ma-team : il affiche le lag par partition. Le jour où une partition dépasse 100 000 messages, il y a un souci : un GC trop long, un appel externe lent, ou une partition hotspot. Ne te précipite pas sur le repartitioning ; check d'abord le consumer, souvent le coupable est côté code.
Au-delà du lag, regarde le taux d'erreur global, les rebalances de groupe et les temps de réponse via les métriques JMX : kafka.server:type=BrokerTopicMetrics pour les brokers, kafka.consumer:type=consumer-fetch-manager-metrics pour les fetchs. Avec Prometheus/Grafana, tu poses des alertes sur le lag et les rebalances fréquentes — un consumer qui reboot en boucle se repère immédiatement. La doc de référence reste Apache Kafka: The Definitive Guide pour tes SLO, mais ton historique de prod est ta meilleure baseline.
Conclusion
Kafka a redéfini les standards de l'event streaming, mais pas grâce à une magie quelconque. C'est un journal distribué, répliqué, qui t'oblige à penser en termes de flux, de partitions et d'offsets. Ceux qui en font une simple file de tâches passent à côté de l'essentiel – et se retrouvent vite avec des scénarios de rejeu impossibles et des schémas ingérables.
Mon expérience terrain est sans appel : les déploiements qui tiennent la route sont ceux qui respectent trois règles. D'abord, un Schema Registry pour gérer l'évolution de tes événements sans casser tes consommateurs. Ensuite, une surveillance active du consumer lag – j'ai vu trop de pipelines silencieusement en rade parce que personne ne regardait cet indicateur. Enfin, une vraie réflexion sur le partitionnement, car une clé mal choisie tue ta garantie d'ordre et ton parallélisme.
Alors oui, Kafka demande une courbe d'apprentissage. Mais une fois que tu as compris cette nuance fondatrice – un log plutôt qu'une queue – tu ne peux plus revenir en arrière. Tu n'utilises plus Kafka comme un outil de plus, tu conçois tes systèmes autour du flux d'événements. C'est ça, la redéfinition des standards.