Apache Kafka explique par celui qui gere 1.4M messages/seconde
Le jour ou j'ai compris que Kafka changeait tout
En 2018, j'arrive au Credit Agricole pour une mission de 3 mois. 6 ans plus tard, je gere toujours leurs 47 clusters Kafka, 67 000 topics et 1.4 million de messages par seconde.
Pourquoi ? Parce que Kafka n'est pas juste un outil. C'est le systeme nerveux des entreprises modernes.
Les memes concepts que j'explique aux architectes du CAC 40 - sans le jargon inutile. En 10 minutes, vous comprendrez pourquoi Kafka est devenu incontournable.
Le probleme que Kafka resout (et que vous avez peut-etre)
Avant : L'Enfer des Connexions Point-a-Point
Imaginez : vous avez 10 applications. Chacune doit parler aux autres.
Resultat : 10 × 9 = 90 connexions a maintenir. Ajoutez une 11eme application : 110 connexions.
J'ai vu des architectures avec 200+ services et des equipes entieres dediees juste a gerer les integrations. Une folie.
Apres : Le Hub Central
Avec Kafka, chaque application se connecte a un seul point.
10 applications = 20 connexions (10 producers + 10 consumers) 100 applications = 200 connexions (pas 9 900)
Chez un client assureur, on est passe de 3 semaines pour integrer un nouveau service a 2 jours. Le ROI s'est calcule en mois, pas en annees.
| Critere | Architecture Point-a-Point | Architecture Kafka |
|---|---|---|
| Complexite | O(N²) - explose | O(N) - lineaire |
| Ajout d'un service | Modifier N services | Zero modification |
| Panne d'un service | Cascade potentielle | Isole |
| Historique | Perdu | Conserve (replay) |
Les 5 concepts que vous devez vraiment comprendre
1. Le Message : L'Unite de Base
Un message Kafka, c'est comme un email professionnel :
- Destinataire (topic) : ou l'envoyer
- Objet (key) : pour trier et router
- Corps (value) : le contenu reel
- Date (timestamp) : quand c'etait envoye
En production, on utilise generalement du JSON ou Avro. Chez mes clients, Avro domine car il permet de valider la structure des messages automatiquement.
2. Le Topic : La Boite aux Lettres Thematique
Un topic = une categorie de messages.
Exemples reels que je vois en mission :
orders.created- Nouvelles commandespayments.validated- Paiements confirmesinventory.updated- Mise a jour des stocksusers.logged-in- Connexions utilisateurs
Ne creez pas un topic events fourre-tout. J'ai vu des equipes perdre des mois a demeler un topic de 50 types d'evenements differents. Un topic = un type d'evenement.
3. Les Partitions : La Cle de la Performance
Un topic se divise en partitions pour traiter les messages en parallele.
Regle d'or : Plus de partitions = plus de throughput, mais aussi plus de complexite.
| Volume attendu | Partitions recommandees |
|---|---|
| < 10K msg/sec | 3-6 partitions |
| 10K-100K msg/sec | 12-24 partitions |
| > 100K msg/sec | 50+ (necessité d'analyse) |
Chez le Credit Agricole, on commence souvent a 6 partitions par defaut. C'est suffisant pour 90% des cas et ca evite les problemes de rebalancing.
4. Producers et Consumers : Qui Envoie, Qui Recoit
- Producer : l'application qui envoie des messages
- Consumer : l'application qui les lit
La beaute du systeme : un producer ne sait pas qui va lire ses messages. Un consumer ne sait pas qui les a envoyes. Decouplage total.
5. Consumer Groups : Le Travail d'Equipe
Plusieurs consumers peuvent former un groupe pour se repartir le travail.
Topic "orders" (3 partitions)
│
┌────┼────┐
▼ ▼ ▼
P0 P1 P2
│ │ │
▼ ▼ ▼
[C1] [C2] [C3] ← Consumer Group "order-processing"
Une partition = un consumer max par groupe. Si vous avez 3 partitions et 5 consumers dans le meme groupe, 2 resteront inactifs. J'ai vu des equipes deployer des dizaines de pods Kubernetes pour rien.
Cas d'usage reels (pas de la theorie)
1. Synchronisation Base de Donnees → Data Lake
Le cas : Un client retail voulait analyser ses ventes en temps reel, mais sa base Oracle ne pouvait pas supporter les requetes analytiques en plus du transactionnel.
La solution :
Oracle ──[Debezium CDC]──> Kafka ──> Snowflake
└───> Elasticsearch (recherche)
└───> ML Pipeline (recommendations)
Resultat : Analyses passees de J+1 a temps reel, sans toucher a Oracle.
2. Architecture Event-Driven Microservices
Le cas : Une banque avec 150 microservices qui se parlaient en REST synchrone. Latence de 2-3 secondes pour certaines operations.
La solution : Evenements asynchrones via Kafka.
Resultat : Latence reduite a < 100ms, plus de timeouts en cascade.
3. Collecte de Logs a Grande Echelle
Le cas : 500 serveurs generant 2 To de logs par jour. L'ELK Stack saturait.
La solution : Kafka comme buffer devant Elasticsearch.
Resultat : Zero perte de logs, meme pendant les pics.
Par ou commencer (mon conseil)
Option 1 : Decouverte locale (5 minutes)
# Le moyen le plus simple pour tester
docker run -d --name redpanda -p 9092:9092 vectorized/redpanda
Redpanda est compatible Kafka, sans la complexite de ZooKeeper.
Option 2 : Formation structuree
J'ai cree une formation gratuite dans l'espace membre qui couvre :
- Installation production-ready
- Patterns d'architecture
- Monitoring et alerting
- Troubleshooting
Acceder a la formation gratuite →
Option 3 : Accompagnement projet
Si vous avez un projet concret (migration, nouvelle architecture, optimisation), discutons-en. Un audit initial gratuit de 30 minutes peut vous eviter des mois d'erreurs.
Ce que 10 ans m'ont appris sur Kafka
- Kafka n'est pas magique - C'est puissant, mais ca demande de l'expertise pour bien l'operer
- Le sizing initial est critique - Trop de partitions tue la performance autant que trop peu
- Le monitoring n'est pas optionnel - Consumer lag, under-replicated partitions... sans alertes, vous apprendrez les problemes par vos utilisateurs
- La retention a un cout - Garder 30 jours de donnees sur 1.4M msg/sec, ca fait beaucoup de disques
- L'equipe compte plus que l'outil - J'ai vu des Kafka excellents plantes par manque de formation
Prochaines etapes
Debutant : Inscrivez-vous a l'espace membre pour acceder aux formations gratuites.
Intermediaire : Explorez mes autres articles sur le monitoring Kafka et les patterns CDC avec Debezium.
Projet en cours : Contactez-moi pour un audit gratuit de 30 minutes.
Florian Courouge gere les plateformes Kafka de grands groupes francais depuis 2016. Actuellement responsable de 47 clusters, 67K topics et 1.4M messages/seconde au Credit Agricole. Speaker Confluent Paris 2019 & 2020.