Les partitions Kafka, un goulot d’étranglement insidieux
Le modèle de partitionnement de Kafka reste invisible… jusqu’à ce qu’il ne le soit plus. Quand l’ordre des messages est rompu ou que les consommateurs restent inactifs tandis que les files s’accumulent, la cause remonte souvent à une décision de partitionnement prise des années plus tôt et oubliée. Chaque partition est une voie de circulation unique : plus de voies permettent plus de véhicules, mais trop peu créent des embouteillages, tandis que des voies mal choisies perturbent totalement le flux.
Les deux limites incontournables à connaître
D’abord, le parallélisme dépend du nombre de partitions. Chaque consommateur d’un groupe ne peut traiter qu’une seule partition à la fois. Six partitions signifient donc six consommateurs actifs au maximum, même si vous en lancez davantage. Ensuite, l’ordre est restreint à une partition. Les événements partageant la même clé restent séquentiels, mais des clés dispersées entre partitions arrivent hors séquence. Choisir une mauvaise clé ou omettre le partitionnement par clé force l’équipe à des semaines de débogage pour comprendre pourquoi la session d’un utilisateur semble désordonnée.
Des clés qui répartissent la charge, pas les goulots
Le partitionnement par clé est la solution par défaut pour une bonne raison : il regroupe les événements d’une même entité au même endroit. Un identifiant d’utilisateur ou de commande répartit naturellement la charge, car ces valeurs sont nombreuses et variées. En revanche, des clés comme le statut ou la région attirent le trafic : 80 % des événements atterrissent dans quelques partitions seulement, créant des points chauds qui ralentissent l’ingestion et privent les autres consommateurs de ressources. Avant de choisir une clé, vérifiez qu’elle offre une cardinalité élevée et une répartition équilibrée ; sinon, reconsidérez votre choix.
Quand abandonner la clé — et ce que vous perdez
L’absence de clé permet à Kafka répartir les messages uniformément, optimisant le débit et l’équilibre du cluster. C’est le bon choix pour les logs ou les métriques, où l’ordre n’a pas d’importance. Mais dès que vous devez rejouer le cycle de vie d’une commande ou reconstituer l’état d’un appareil, l’absence de garantie d’ordre devient un handicap. Le compromis est clair : pas de clé, pas d’ordre.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.