Diagramme d'architecture Kafka : brokers, partitions, réplicas et consumer groups

Kafka se dessine facilement comme une seule boîte étiquetée « Kafka » avec des flèches qui entrent et qui sortent, et cette boîte cache toutes les propriétés sur lesquelles on compte : ce qui est ordonné et ce qui ne l'est pas, combien de copies des données existent, ce qui se passe quand un broker tombe, et comment plusieurs services peuvent lire le même flux sans se marcher dessus.

Cet article dessine un cluster Kafka avec les éléments qui comptent : brokers, topics et partitions, réplicas leader et followers, producteurs avec clés, consumer groups et offsets, et les contrôleurs KRaft qui gèrent le cluster.

Topics, partitions et brokers

Un topic est un flux nommé d'enregistrements, comme orders. Chaque topic est découpé en partitions, et chaque partition est un log en ajout seul où chaque enregistrement reçoit un offset croissant.

Les partitions sont l'unité de tout :

• Ordre : les enregistrements sont ordonnés au sein d'une partition, jamais entre partitions.
• Parallélisme : un topic peut être consommé par au plus autant de consommateurs d'un même groupe qu'il a de partitions.
• Placement : les partitions sont réparties sur les brokers, les serveurs du cluster.

Choisissez le nombre de partitions d'après le débit nécessaire par topic et le nombre de consommateurs que vous voulez faire tourner en parallèle, avec de la marge. On peut ajouter des partitions plus tard, mais cela change la partition vers laquelle une clé est envoyée.

Réplication

Chaque partition a un facteur de réplication, généralement 3. Un réplica est le leader et traite les lectures et écritures ; les autres sont des followers qui copient le log du leader. Les followers à jour forment l'ensemble des réplicas synchronisés (ISR). Si le broker d'un leader tombe, un follower à jour devient le nouveau leader.

Les réglages qui décident de la durabilité :

Avec un facteur 3, min.insync.replicas=2 et acks=all, une écriture confirmée existe sur au moins deux brokers, et le cluster continue d'accepter des écritures avec un broker en panne. La documentation de Kafka couvre ces réglages et leurs interactions.

Producteurs et clés

Les producteurs choisissent une partition pour chaque enregistrement. Avec une clé, le partitionneur par défaut hache la clé : tous les enregistrements de même clé arrivent dans la même partition et restent ordonnés. Sans clé, les enregistrements sont répartis pour l'équilibre et perdent tout ordre entre eux.

Choisissez les clés d'après l'entité dont les événements doivent rester ordonnés : un ID de commande, un ID de compte. Écrivez la clé sur le producteur dans le diagramme ; c'est le réglage le plus lourd de conséquences d'un producteur. Évitez les clés à quelques valeurs énormes, car une clé chaude surcharge une partition, quel que soit le nombre de partitions.

Les retries peuvent dupliquer des enregistrements. Les versions récentes de Kafka activent par défaut les producteurs idempotents, qui suppriment les doublons dus aux retries du producteur au sein d'une partition ; les doublons dus aux retries de votre propre application restent possibles, donc les consommateurs doivent aussi être idempotents.

Consumer groups et offsets

Un consumer group est un ensemble de consommateurs qui se partagent le travail pour un même objectif. Kafka attribue chaque partition à exactement un consommateur du groupe : trois partitions peuvent donc occuper au plus trois consommateurs, un quatrième resterait inactif. Quand des consommateurs arrivent ou partent, le groupe se rééquilibre et les partitions se déplacent.

Chaque groupe suit sa propre position, l'offset validé par partition, que Kafka stocke dans un topic interne. C'est ainsi que plusieurs services lisent le même flux de façon indépendante : fulfillment et analytics ont chacun leur groupe et leurs offsets, et aucun n'affecte l'autre.

Validez les offsets après le traitement, pas avant, et vous obtenez un traitement au moins une fois : après un crash, le consommateur retraite les enregistrements depuis la dernière validation. Rendez le traitement idempotent pour que les répétitions soient sans effet.

Rétention et compaction

Kafka conserve les enregistrements après leur lecture. La rétention par durée ou par taille supprime les anciens segments, par exemple au bout de 7 jours. La compaction de log conserve au contraire pour toujours le dernier enregistrement de chaque clé, ce qui transforme un topic en changelog de l'état courant. Choisissez par topic : les événements utilisent en général la rétention, un état comme « dernière adresse par client » utilise la compaction.

Un exemple de dimensionnement

Disons que le checkout produit 3 000 événements de commande par seconde au pic, d'environ 1 Ko chacun, soit 3 Mo/s. Un consommateur du service fulfillment traite 400 événements par seconde. Il vous faut au moins 8 consommateurs en parallèle au pic, donc au moins 8 partitions ; choisissez-en 12 pour laisser de la place à la croissance et aux partitions d'un consommateur en panne. Avec un facteur de réplication 3, le cluster écrit 9 Mo/s sur disque répartis entre les brokers, et 7 jours de rétention à ce rythme stockeraient jusqu'à environ 5,4 To de données répliquées. Le trafic moyen est inférieur au pic : voyez ce chiffre comme le plafond pour planifier les disques. Ces chiffres ont leur place à côté du diagramme, car ce sont eux qui déterminent le nombre de brokers et les disques, pas la boîte étiquetée Kafka.

KRaft : fini ZooKeeper

Les anciens clusters stockaient leurs métadonnées dans ZooKeeper. Kafka gère désormais lui-même ses métadonnées avec un quorum de contrôleurs fondé sur Raft, appelé KRaft. Kafka 4.0, sorti en mars 2025, est la première version majeure qui fonctionne entièrement sans ZooKeeper. Sur un diagramme, dessinez le quorum de contrôleurs séparément des brokers, même quand de petits clusters font tourner les deux rôles sur les mêmes machines.

Le diagramme d'architecture

Comment le lire :

• À gauche : deux producteurs envoient des événements avec l'ID de commande comme clé. La commande 8812 est hachée vers la partition 0, la commande 9001 vers la partition 2.
• Au milieu : trois brokers, chacun leader d'une partition et follower des deux autres. Les arêtes en tirets montrent la réplication ; les contrôleurs KRaft en dessous gèrent les métadonnées et l'élection des leaders.
• À droite : le groupe fulfillment compte trois consommateurs, un par partition. Le consommateur analytics appartient à un autre groupe : il lit donc chaque événement avec ses propres offsets.
• Le bloc Markdown liste les réglages du topic dont dépend le schéma.

Ce qu'il faut mettre sur un diagramme Kafka

• Les partitions par topic et la clé, car elles définissent l'ordre et le parallélisme.
• Le facteur de réplication et min.insync.replicas, car ils définissent la durabilité.
• Chaque consumer group par son nom, avec ses consommateurs.
• La rétention ou la compaction de chaque topic.
• Qui produit et qui consomme, d'un service à l'autre, pour que la responsabilité soit claire.

Pour les patterns construits sur Kafka, voyez le diagramme d'architecture orientée événements, le pattern transactional outbox pour publier de façon fiable depuis une base de données, et le diagramme d'architecture d'un pipeline de données pour Kafka comme source de l'analytique.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez des nœuds Conteneur du pack Modèle C4 pour les producteurs, avec leur clé dans la description.
3. Ajoutez trois nœuds Kafka du pack Données pour les brokers, étiquetés avec les partitions dont chacun est leader ou follower, et un Conteneur pour les contrôleurs KRaft.
4. Ajoutez un Cadre du pack Base pour le consumer group avec un Conteneur par consommateur, plus un consommateur séparé pour le second groupe.
5. Dessinez la réplication en arêtes en tirets et ajoutez un bloc Markdown du pack Base avec les réglages du topic.

L'exemple utilise 12 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Kafka garantit-il l'ordre des messages ? Au sein d'une partition, oui. Entre partitions, non. Utilisez une clé pour que les enregistrements qui doivent rester ordonnés partagent une partition.

Combien de partitions un topic doit-il avoir ? Assez pour le débit nécessaire et le nombre de consommateurs que vous voulez en parallèle, avec de la marge pour grandir. Changer ce nombre plus tard change la façon dont les clés sont associées aux partitions.

Que se passe-t-il quand un broker tombe ? Pour chaque partition dont il était leader, un follower à jour sur un autre broker devient leader. Avec un facteur de réplication 3 et min.insync.replicas=2, les écritures continuent.

Qu'est-ce qu'un consumer group ? Un ensemble de consommateurs qui se répartissent les partitions d'un topic. Des groupes différents lisent le même topic de façon indépendante, chacun avec ses propres offsets.

Kafka a-t-il encore besoin de ZooKeeper ? Non. Kafka 4.0 et les versions suivantes fonctionnent uniquement en mode KRaft, où un quorum de contrôleurs gère les métadonnées du cluster.

Commencez gratuitement — un siège, sans carte bancaire.