La plupart des dimensionnements Kafka partent du débit. La rétention, le nombre de partitions et la fenêtre de reprise décident davantage — et ce sont les chiffres qu’on saute.
Le débit est le premier chiffre qu’on demande, et c’est rarement la contrainte. Un cluster de trois brokers sur du matériel ordinaire absorbe plus que ce que produisent la plupart des organisations. Ce qui dimensionne réellement le cluster, c’est la durée de conservation des données, le nombre de partitions et la vitesse à laquelle il faut être revenu après la perte d’un broker.
La rétention est une décision de stockage
Sept jours de rétention à 200 Mo/s représentent environ 120 To avant réplication, et trois fois plus après. Les équipes règlent souvent la rétention « au cas où » et découvrent la facture ensuite. La rétention se décide par sujet, pas par cluster.
Le nombre de partitions est une décision de rééquilibrage
Les partitions sont bon marché jusqu’à ce qu’elles ne le soient plus. Chaque partition est un descripteur de fichier ouvert, un flux de réplication et une unité de travail de rééquilibrage. Un cluster à 200 000 partitions ne tombe pas sur le débit ; il tombe sur les vingt minutes nécessaires à l’élection des leaders après un redémarrage progressif.
La fenêtre de reprise est la vraie exigence
Demandez ce qui se passe quand un broker meurt en pleine journée. Si la réponse est « il faut être revenu en dix minutes », le cluster est dimensionné par la vitesse de rattrapage de la réplication, pas par le pic d’écriture. Cette seule question change le type de disque, la taille des instances et le nombre de brokers, bien plus que n’importe quel chiffre de débit.
Ce que nous faisons en premier
Avant de proposer une topologie, nous mesurons une semaine de trafic réel et en tirons trois chiffres : pic d’écriture soutenu, rétention réellement nécessaire par sujet, et fenêtre de reprise acceptable. Tout le reste en découle.