Apache Kafka : tour d'horizon complet

LinkedIn, 2010. L’équipe data se retrouve avec un problème structurel : des dizaines de systèmes — tracking d’activité utilisateur, métriques opérationnelles, logs, pipelines Hadoop — qui ont tous besoin de se parler, et aucune façon propre de les connecter. La solution de l’époque ? Des pipelines point-à-point, un par paire de systèmes. Résultat : un graphe de dépendances ingérable.

C’est dans ce contexte que Jay Kreps, Neha Narkhede et Jun Rao décident d’écrire Kafka. Pas un message broker de plus — une plateforme de streaming d’événements distribuée, pensée pour l’échelle et la durabilité.

Cet article est un tour d’horizon : pourquoi Kafka a été créé, qui l’a créé, ce qu’il est réellement, comment ça marche, et où en est l’écosystème aujourd’hui (Kafka 4.2, juin 2026).

1. Avant Kafka : le chaos des pipelines point-à-point

Le problème à LinkedIn en 2010

À cette époque, LinkedIn gérait plusieurs systèmes qui produisaient et consommaient des données :

tracking d’activité utilisateur (clics, visites de profils, recherches)
métriques opérationnelles des serveurs
flux de données vers Hadoop pour l’analyse batch
systèmes de recommandation et de recherche

La première solution naturelle : connecter chaque système directement à ceux dont il a besoin. Si le système A doit envoyer des données à B, C et D, on crée trois connexions. Si E a besoin de données de A et B, on crée deux connexions de plus.

Ça marche jusqu’à un certain point. Passé une dizaine de systèmes, la topologie explose. Chaque nouveau service doit réimplémenter la logique de connexion, de retry, de buffering. Il n’y a pas de place centrale pour rejouer un événement passé. Ajouter un nouveau consommateur signifie modifier le producteur.

Avant Kafka — topologie point-à-point

[Tracking]──────▶[Hadoop]
[Tracking]──────▶[Recommandations]
[Tracking]──────▶[Recherche]
[Métriques]─────▶[Hadoop]
[Métriques]─────▶[Alerting]
[Logs]──────────▶[Hadoop]
[Logs]──────────▶[Alerting]

→ N producteurs × M consommateurs = N×M connexions à maintenir

Source : Kafka’s origin story at LinkedIn

Ce qui existait : ActiveMQ et RabbitMQ

Les solutions de message queuing disponibles à l’époque avaient un modèle fondamentalement différent.

ActiveMQ (2004) était le standard Java entreprise. Conforme JMS, il excelle dans les scénarios d’intégration enterprise complexes avec du routage sophistiqué. Mais son architecture centralisée et sa gestion des messages en mémoire ne le rendaient pas adapté à des millions de messages par seconde.

RabbitMQ (2007), basé sur le protocole AMQP, résout le problème du routage flexible avec ses exchanges et ses bindings. Sa sémantique est claire : un message est envoyé, traité, supprimé. Le producteur a confirmation de la livraison, le consommateur accuse réception.

Les deux partagent un problème critique pour le cas d’usage LinkedIn :

Les messages sont éphémères. Une fois consommé, un message disparaît. Il est impossible de rejouer un événement passé.
Le throughput est limité. Ces systèmes sont optimisés pour la fiabilité du routage, pas pour des millions de messages/seconde.
Ajouter un consommateur est intrusif. Dans une queue classique, chaque consommateur consomme une partie des messages. Pour que deux consommateurs voient tous les messages, il faut dupliquer la queue.

Source : RabbitMQ vs Kafka vs ActiveMQ — AWS

2. Jay Kreps : qui a écrit Kafka ?

Parcours

Jay Kreps fait ses études à UC Santa Cruz (BS en informatique 2002, MS 2005). Il travaille ensuite comme ingénieur chez Movaris, puis chez NexTag sur des systèmes de data mining. En 2007, il rejoint LinkedIn comme Principal Staff Engineer, où il devient le lead technique des systèmes de données — infrastructure de stockage, moteur de recherche, système de recommandation, et le projet qui allait devenir Kafka.

En 2014, avec Neha Narkhede et Jun Rao, il co-fonde Confluent, la société commerciale construite autour de Kafka. Il en est toujours le CEO aujourd’hui.

Pourquoi le nom “Kafka” ?

Jay Kreps a nommé le logiciel en hommage à l’écrivain Franz Kafka, expliquant que c’est “un système optimisé pour l’écriture” et qu’il appréciait son œuvre. Le nom n’a pas de signification technique particulière — c’est un choix personnel.

Source : The Evolution of Apache Kafka — Confluent podcast ft. Jay Kreps

Open source et Apache Software Foundation

Kafka est open-sourcé en juin 2011 et donné à l’Apache Software Foundation. Il sort de l’incubateur Apache le 23 octobre 2012. En 2014, les trois fondateurs créent Confluent pour proposer une offre managée et commerciale autour de Kafka.

3. Ce que Kafka est (vraiment)

Kafka se décrit lui-même comme une plateforme de streaming d’événements distribuée. Pas un message broker, pas une queue — même si on peut l’utiliser comme tel. La distinction est importante.

La différence fondamentale avec RabbitMQ ou ActiveMQ : les messages ne sont pas détruits après consommation. Kafka est un log distribué, une structure append-only. Les événements s’accumulent, sont répliqués, et persistent pendant une durée configurable (ou indéfiniment). Plusieurs consommateurs indépendants peuvent lire le même flux, chacun à son propre rythme, sans interférer.

Modèle Kafka — le log distribué

Producteurs               Topic "user-events"              Consommateurs
                     ┌─────────────────────────────┐
[App web]──────────▶ │ offset: 0  1  2  3  4  5  6 │──▶ [Recommandations] (offset 6)
[App mobile]───────▶ │ [e1][e2][e3][e4][e5][e6][e7]│──▶ [Analytics]       (offset 4)
[Service paiement]─▶ │                             │──▶ [Audit]           (offset 7)
                     └─────────────────────────────┘
                          ↑ les messages restent

Source : Introduction — Apache Kafka

4. Les concepts clés

4.1 Topic

Un topic est un canal logique nommé. Les producteurs y publient des événements, les consommateurs s’y abonnent. Un topic est un log append-only : on ne modifie pas les messages passés, on ajoute toujours à la fin.

Exemple concret : commandes, paiements, livraisons, clics-utilisateur.

4.2 Partition

Chaque topic est divisé en une ou plusieurs partitions. C’est l’unité fondamentale de parallélisme et de distribution dans Kafka.

À l’intérieur d’une partition, les messages sont ordonnés et numérotés séquentiellement (offset 0, 1, 2…).
Les partitions d’un même topic sont réparties sur différents brokers.
Le nombre de partitions détermine le degré de parallélisme : on ne peut pas avoir plus de consommateurs actifs que de partitions pour un topic donné.

Topic "commandes" — 3 partitions réparties sur 3 brokers

Broker 1: Partition 0 [msg0][msg3][msg6][msg9]
Broker 2: Partition 1 [msg1][msg4][msg7]
Broker 3: Partition 2 [msg2][msg5][msg8]

La clé du message détermine dans quelle partition il atterrit (hash de la clé % nombre de partitions). Tous les messages avec la même clé vont dans la même partition — et sont donc ordonnés entre eux. Sans clé, Kafka répartit en round-robin.

Source : Kafka Topics, Partitions, Brokers — Conduktor

4.3 Broker

Un broker est un serveur Kafka. Un cluster Kafka est composé de plusieurs brokers. Chaque broker stocke certaines partitions et répond aux requêtes des producteurs et consommateurs. La réplication des partitions entre brokers assure la tolérance aux pannes.

En production, un facteur de réplication de 3 est standard : chaque partition a un leader (qui gère les lectures et écritures) et deux répliques (followers qui se synchronisent). Si un broker tombe, un follower est élu leader automatiquement.

4.4 Producteur

Un producteur publie des messages dans des topics. Il choisit la clé (pour le routage vers une partition), peut batcher les messages pour optimiser le throughput, et peut configurer le niveau d’accusé de réception (acks) : 0 (fire and forget), 1 (leader a reçu), ou all (tous les réplicas ont reçu).

4.5 Consommateur et Consumer Group

Un consommateur lit des messages depuis un topic. Il maintient lui-même la position de lecture (l’offset) et peut la committer dans Kafka pour reprendre là où il s’est arrêté en cas de redémarrage.

La notion de consumer group est centrale : un ensemble de consommateurs qui travaillent ensemble pour traiter un topic. Chaque partition n’est assignée qu’à un seul consommateur du groupe à la fois. Si le groupe a 3 consommateurs et le topic a 6 partitions, chaque consommateur traite 2 partitions en parallèle.

Consumer Group "analytics" — 3 consommateurs, 6 partitions

Consommateur A ──▶ Partition 0, Partition 1
Consommateur B ──▶ Partition 2, Partition 3
Consommateur C ──▶ Partition 4, Partition 5

Deux consumer groups indépendants lisent le même topic de manière totalement indépendante. C’est ce qui permet à plusieurs systèmes de consommer le même flux sans interférer.

4.6 Offset

L’offset est le numéro de séquence d’un message au sein d’une partition. Les consommateurs committent périodiquement leur offset pour indiquer jusqu’où ils ont traité. En cas de panne, ils reprennent depuis le dernier offset commité.

Cette gestion explicite de l’offset est une des forces de Kafka : on peut délibérément rembobiner un consommateur pour rejouer des événements passés.

Partition 0 :   [0][1][2][3][4][5][6][7]
                                  ↑
                    Consommateur X — offset committé : 5
                    Au prochain démarrage, reprend à 5

Source : Redpanda — Kafka topics guide

5. Architecture interne : pourquoi c’est rapide

Log séquentiel et zero-copy

Kafka stocke les messages sur disque dans des fichiers séquentiels. L’écriture séquentielle sur disque est massivement plus rapide que l’accès aléatoire — sur un disque rotatif, on peut atteindre des débits comparables à la RAM pour les écritures séquentielles.

Pour la lecture, Kafka exploite le page cache du système d’exploitation. Les données récemment écrites sont mises en cache en mémoire par l’OS ; Kafka n’a donc pas besoin de gérer un cache applicatif. Il évite aussi de stocker les données dans le heap JVM, contournant ainsi les problèmes de garbage collection.

La technique zero-copy (sendfile) permet de transférer des données du page cache vers le socket réseau sans passer par l’espace utilisateur, réduisant drastiquement les copies mémoire.

Source : Design — Apache Kafka

Batching et compression

Producteurs et brokers regroupent les messages en batches avant de les envoyer. La compression (gzip, snappy, lz4, zstd) est appliquée au batch entier, avec de meilleurs ratios qu’à la compression message par message.

6. KRaft : Kafka sans ZooKeeper (Kafka 4.0+)

L’ancien problème : ZooKeeper

Historiquement, Kafka dépendait d’Apache ZooKeeper pour gérer les métadonnées du cluster : quels brokers sont actifs, qui est leader de quelle partition, la liste des topics. Déployer Kafka signifiait déployer et opérer deux systèmes distincts.

KRaft : le consensus intégré

KRaft (Kafka Raft) implémente le protocole Raft directement dans Kafka pour gérer les métadonnées. Les métadonnées sont stockées dans un topic interne @metadata, répliqué sur un quorum de nœuds contrôleurs.

Kafka 4.0 (mars 2025) a supprimé le support ZooKeeper. La version actuelle est 4.2.0 (février 2026).

Bénéfices concrets :

un seul système à déployer, monitorer, déboguer
scalabilité des métadonnées améliorée (ZooKeeper devenait un goulot au-delà de ~200 000 partitions)
recovery après panne plus rapide

Source : Apache Kafka 4.0.0 Release Announcement

7. L’écosystème Kafka

Kafka seul gère le transport d’événements. L’écosystème qui l’entoure en fait une plateforme complète.

7.1 Kafka Connect

Kafka Connect est un framework pour connecter Kafka à des systèmes externes sans écrire de code. Il propose deux types de connecteurs :

Source connectors : lisent depuis une source (base de données, S3, Salesforce…) et publient dans Kafka
Sink connectors : lisent depuis Kafka et écrivent vers une destination (Elasticsearch, PostgreSQL, BigQuery…)

Des centaines de connecteurs sont disponibles en open source ou chez Confluent. Le pattern CDC (Change Data Capture) avec Debezium permet par exemple de streamer chaque changement d’une base PostgreSQL vers Kafka.

7.2 Kafka Streams

Kafka Streams est une bibliothèque Java pour écrire des applications de traitement de flux directement sur Kafka, sans cluster dédié (pas de Spark, Flink, ou autre). Elle s’intègre comme une dépendance Maven ordinaire.

Elle permet les opérations classiques de stream processing : filter, map, groupBy, join entre topics, fenêtres temporelles, agrégations. L’état local est stocké dans RocksDB, répliqué dans Kafka pour la tolérance aux pannes.

7.3 Schema Registry

Le Schema Registry (Confluent, open source) gère les schémas des messages Kafka — en Avro, Protobuf ou JSON Schema. Il garantit la compatibilité des schémas entre producteurs et consommateurs au fil des évolutions.

Sans Schema Registry, rien n’empêche un producteur de changer le format d’un message et de casser silencieusement tous les consommateurs.

8. Qui utilise Kafka et pour quoi ?

Logique : LinkedIn a créé Kafka et l’utilise massivement. En 2019, LinkedIn traitait déjà 7 trillions de messages par jour. Cas d’usage : tracking d’activité utilisateur, métriques d’infrastructure, pipelines vers Hadoop, recommandations en temps réel.

Source : How LinkedIn uses Apache Kafka in production — Factor House

Netflix

Chaque clic, lecture, pause sur Netflix génère un événement envoyé à Kafka. Ces événements alimentent la personnalisation en temps réel, les systèmes de recommandation, et la détection d’anomalies opérationnelles. Netflix traite des milliards d’événements par jour, permettant aux équipes de détecter des problèmes de streaming avant que les utilisateurs ne s’en aperçoivent.

Uber

Uber qualifie Kafka de “cornerstone of our technology stack”. Chaque mise à jour de position de chauffeur, chaque demande de course, chaque paiement est un événement Kafka. Les systèmes en aval calculent l’ETA, le surge pricing, la disponibilité des chauffeurs en temps réel. Uber traite plusieurs pétaoctets de données par jour.

Source : Apache Kafka in 2025: Why Netflix and Uber Rely on It

Airbnb

Chez Airbnb, Kafka centralise les événements de recherche, réservation et interactions utilisateur. Il connecte les frameworks d’expérimentation A/B, les systèmes d’analytics et les outils de monitoring.

Autres cas d’usage courants

Fraud detection (banques, fintechs) : analyser les transactions en temps réel pour détecter des patterns suspects
IoT : ingérer des flux de capteurs à haute fréquence
Log aggregation : centraliser les logs applicatifs de milliers de services
Event sourcing : stocker l’état d’une application comme une séquence d’événements immuables
CQRS : séparer les opérations de lecture et d’écriture via des topics

Source : Powered By — Apache Kafka

9. Kafka est-il fait pour moi ? Comparaison avec les alternatives

Critère	Kafka	RabbitMQ	ActiveMQ
Modèle	Log distribué, pub-sub	Message queue, routage flexible	JMS, entreprise Java
Throughput	Très élevé (millions msg/s)	Élevé (< Kafka sous charge)	Modéré
Persistance	Configurable, longue durée	Transitoire (ACK → suppression)	Transitoire
Replay	Oui (offset manuel)	Non	Non
Ordre garanti	Par partition	Oui (une queue)	Oui (une queue)
Routage complexe	Non	Oui (exchanges, bindings)	Oui (JMS selectors)
Complexité opérationnelle	Élevée (cluster dédié)	Modérée	Faible à modérée
Cas d’usage idéal	Streaming, event sourcing, gros volumes	Microservices, task queues, RPC asynchrone	Intégration entreprise Java

En pratique, si le besoin est de traiter des millions d’événements par seconde, de rejouer des événements passés, ou de connecter de nombreux systèmes à un flux unique, Kafka est le bon outil. Pour une application qui envoie des tâches à des workers (job queue) ou fait du request-reply asynchrone, RabbitMQ est plus simple à opérer et plus adapté.

Source : RabbitMQ vs Kafka — DesignGurus

10. En quoi Kafka est-il codé ?

Kafka est écrit principalement en Scala pour le broker, et en Java pour les clients. L’ensemble tourne sur la JVM.

Le choix de Scala/JVM en 2010 était cohérent avec l’environnement LinkedIn (stack Java), et Scala offrait des abstractions fonctionnelles utiles pour le traitement de données. Les clients modernes existent dans pratiquement tous les langages (Java, Python, Go, Rust, Node.js…) via des bibliothèques tierces ou le protocole binaire Kafka.

Le problème JVM et comment Kafka le contourne

La JVM pose deux défis pour un système de messagerie haute performance :

Garbage collection : des pauses GC de quelques millisecondes peuvent introduire de la latence. Kafka contourne le problème en ne stockant presque rien dans le heap JVM — les données vivent sur le disque et dans le page cache OS.
Overhead mémoire des objets Java : un objet Java occupe bien plus de mémoire que les données brutes. Kafka évite ce problème de la même façon : les données en transit restent dans le filesystem.

Source : Design — Apache Kafka

11. Courbe d’apprentissage

Phase 1 — Comprendre les concepts (1-2 jours)

Avant d’écrire la moindre ligne de code, il faut avoir le modèle mental correct : ce qu’est un topic, ce que change le nombre de partitions, pourquoi l’offset est géré par le consommateur, comment les consumer groups parallélisent.

Sans ces bases, la configuration semble arbitraire et les problèmes de production sont mystérieux.

Phase 2 — Premier producteur/consommateur (4-6 heures)

Installer Kafka localement (ou via Docker), écrire un producteur et un consommateur basiques. En Java ou Python, les bibliothèques sont bien documentées. Cette étape est rapide.

Phase 3 — Concepts intermédiaires (plusieurs jours)

Comprendre la réplication, les leaders et les ISR (In-Sync Replicas)
Configurer les garanties de livraison (acks, enable.idempotence)
Comprendre exactly-once semantics et ses implications
Utiliser Kafka Connect pour une intégration concrète

Phase 4 — Opérations de production (semaines à mois)

Monitorer un cluster Kafka (métriques JMX, consumer lag), dimensionner les partitions, gérer les rebalances de consumer groups, configurer la rétention, gérer les upgrades. C’est ici que la courbe monte sérieusement.

Kafka 4.0+ simplifie significativement la phase opérationnelle en supprimant ZooKeeper. C’est un système de moins à comprendre et opérer.

Pour la grande majorité des équipes, une offre managée (Confluent Cloud, AWS MSK, Aiven) est recommandée pour éviter la complexité opérationnelle et se concentrer sur la logique métier.

12. Pièges classiques

Consumer lag silencieux

Si les consommateurs ne traitent pas assez vite, le lag augmente sans déclencher d’erreur. Il faut monitorer activement la métrique consumer_lag par groupe et par partition.

Mauvais nombre de partitions au départ

Le nombre de partitions d’un topic ne peut pas être diminué après création. Augmenter le nombre de partitions change le routing des messages avec clé (les messages avec la même clé peuvent finir dans des partitions différentes). Prendre une décision réfléchie au départ.

Ordre garanti ≠ ordre global

Kafka garantit l’ordre à l’intérieur d’une partition, pas à l’échelle d’un topic entier. Si l’ordre global est critique, il faut utiliser une partition unique (ce qui élimine le parallélisme) ou implémenter une logique de réordonnancement côté consommateur.

Rebalance de consumer group

Quand un consommateur rejoint ou quitte un consumer group, Kafka réaffecte les partitions. Pendant ce rebalance, aucun consommateur n’est actif. Kafka 4.0 a introduit KIP-848 pour rendre ce processus incrémental et moins disruptif.

Conclusion

Kafka a résolu un problème réel chez LinkedIn en 2010 : remplacer une topologie de pipelines point-à-point par un bus d’événements central, scalable, et durable. Sa propriété clé — le log distribué, où les messages persistent et peuvent être rejoués — l’a rendu indispensable pour tous les systèmes qui ont besoin de traiter des événements à grande échelle.

Les points à retenir pour commencer :

Le modèle mental : Kafka est un log, pas une queue. Les messages ne disparaissent pas après consommation.
Les partitions : elles définissent le parallélisme. Bien les dimensionner dès le départ.
L’offset : le consommateur gère sa position de lecture. C’est ce qui permet le replay.
Kafka 4.0+ : plus de ZooKeeper. L’architecture s’est simplifiée.
L’écosystème : Kafka Connect, Kafka Streams et le Schema Registry complètent la plateforme pour la plupart des cas d’usage réels.

La documentation officielle reste la meilleure entrée en matière : kafka.apache.org/intro. Pour une montée en compétence structurée, Confluent propose du contenu gratuit de qualité sur developer.confluent.io.

Sources :