Les entretiens Kafka évaluent votre compréhension du parcours des données dans un journal : comment les topics sont découpés en partitions, quel ordre est garanti, comment les consommateurs se répartissent le travail et ce qui se passe en cas de défaillance. Les questions de mise en situation sur le lag, les doublons et la perte de données sont courantes, car ce sont les problèmes que l'on rencontre en production.
Voici 22 questions avec leurs réponses. Certains détails, comme les valeurs par défaut, varient selon les versions de Kafka : précisez que vous vérifieriez la version utilisée.
Concepts fondamentaux
1. Qu'est-ce que Kafka, et à quoi sert-il ?
Kafka est un journal de commits distribué et répliqué. Les producteurs ajoutent des enregistrements à des topics, et les consommateurs les lisent à leur propre rythme. Il sert au streaming d'événements, aux pipelines de logs et de métriques, au découplage des services, à l'alimentation de systèmes analytiques et au traitement de flux.
2. Que sont les topics, les partitions et les offsets ?
Un topic est un flux d'enregistrements nommé. Chaque topic est découpé en partitions, et chaque partition est un journal ordonné en ajout seul. Chaque enregistrement d'une partition possède un offset, un numéro séquentiel qui identifie sa position. Les offsets ne sont uniques qu'au sein d'une partition.
3. Comment les partitions influent-elles sur l'ordre ?
Kafka ne garantit l'ordre qu'au sein d'une partition. Les enregistrements ayant la même clé vont par défaut dans la même partition, ils conservent donc leur ordre relatif. Entre partitions, il n'y a aucun ordre. Si vous avez besoin de tous les événements d'un client dans l'ordre, utilisez l'ID client comme clé.
4. Qu'est-ce qu'un broker, et quel est le rôle du controller ?
Un broker est un serveur Kafka qui stocke des partitions et sert les clients. Un cluster compte plusieurs brokers. L'un d'eux joue le rôle de controller, qui gère les métadonnées du cluster et le leadership des partitions. Les versions récentes de Kafka utilisent KRaft, un mécanisme de consensus intégré, à la place de ZooKeeper pour ces métadonnées.
5. Comment fonctionne la réplication ?
Chaque partition a un facteur de réplication. Un replica est le leader, qui gère les lectures et les écritures, et les autres sont des followers qui le copient. Les in-sync replicas (ISR) sont ceux qui sont à jour par rapport au leader. Si le leader tombe, un nouveau leader est choisi parmi les ISR.
Producteurs
6. Que signifient les réglages acks ?
| acks | Signification | Compromis |
|---|---|---|
| 0 | Le producteur n'attend aucun accusé de réception | Le plus rapide, peut perdre des données |
| 1 | Le leader accuse réception après écriture | Peut perdre des données si le leader tombe avant la réplication |
| all | Le leader attend tous les in-sync replicas | Durabilité maximale, latence plus élevée |
Pour des écritures durables, utilisez acks=all avec min.insync.replicas défini à au moins 2 et un facteur de réplication de 3.
7. Comment éviter les doublons de messages côté producteur ?
Activez le producteur idempotent (enable.idempotence=true), ce qui permet au broker d'écarter les doublons causés par les retries au sein d'une partition. Pour des écritures qui doivent couvrir plusieurs partitions ou topics de façon atomique, utilisez les transactions.
8. Comment un producteur choisit-il une partition ?
Si vous fournissez une clé, le partitionneur par défaut la hache pour choisir la partition. Sans clé, le producteur répartit les enregistrements entre les partitions (les versions récentes utilisent une approche sticky pour remplir les lots efficacement). Vous pouvez aussi écrire un partitionneur personnalisé.
9. Qu'est-ce qui influe sur le débit d'un producteur ?
Le batching (batch.size, linger.ms), la compression (comme lz4 ou zstd), le nombre de partitions et acks. Des lots plus gros et la compression augmentent généralement le débit au prix d'un peu de latence.
Consommateurs
10. Qu'est-ce qu'un groupe de consommateurs ?
Un ensemble de consommateurs qui se partagent le travail de lecture d'un topic. Chaque partition est attribuée à un seul consommateur du groupe à la fois. Le nombre de consommateurs utiles dans un groupe est donc limité par le nombre de partitions, et les consommateurs en trop restent inactifs.
11. Que se passe-t-il lors d'un rebalance ?
Quand un consommateur rejoint ou quitte le groupe, ou quand les partitions changent, le groupe redistribue les partitions. Lors d'un rebalance classique, la consommation est mise en pause pendant l'opération. Le rebalance coopératif et l'adhésion statique réduisent cette perturbation. Les rebalances fréquents viennent souvent de consommateurs qui mettent trop de temps à traiter (max.poll.interval.ms) ou qui ratent des heartbeats.
12. Comment les offsets sont-ils commités ?
Les consommateurs commitent l'offset du prochain enregistrement à lire, stocké dans un topic interne. L'auto-commit est simple mais peut commiter avant la fin du traitement. Les commits manuels après traitement vous donnent le contrôle sur ce que signifie « terminé ».
13. Que signifient at-most-once, at-least-once et exactly-once ?
- At-most-once : on commit l'offset avant le traitement. Un crash peut entraîner une perte d'enregistrements.
- At-least-once : on traite, puis on commit. Un crash peut provoquer un retraitement, donc des doublons sont possibles.
- Exactly-once : l'effet se produit une seule fois. Dans Kafka, c'est possible au sein de Kafka grâce aux producteurs idempotents, aux transactions et aux consommateurs read_committed. Lorsqu'on écrit vers un système externe, il faut généralement des écritures idempotentes ou une déduplication par clé.
Une bonne réponse précise que le « exactly once » dépend de l'endroit où se produisent les effets de bord.
14. Comment géreriez-vous un poison message qui échoue systématiquement ?
On capture l'erreur, on réessaie un nombre limité de fois, puis on envoie l'enregistrement vers un topic dead-letter avec les détails, on commit l'offset et on continue. On met en place une alerte sur le topic dead-letter pour que quelqu'un enquête.
Opérations et scénarios
15. Le lag des consommateurs augmente. Comment le diagnostiquez-vous ?
- Vérifiez quelles partitions ont du lag. Une seule partition chaude indique une clé déséquilibrée. Du lag partout indique un traitement lent ou trop peu de consommateurs.
- Vérifiez le temps de traitement par enregistrement et les appels en aval, comme une base de données.
- Vérifiez la présence de rebalances fréquents.
- Vérifiez si le débit du producteur a augmenté.
- Corrigez avec plus de consommateurs (jusqu'au nombre de partitions), un traitement plus rapide, un traitement par lots ou plus de partitions.
16. Quand faut-il augmenter le nombre de partitions ?
Quand vous avez besoin de plus de parallélisme que ce que les consommateurs actuels peuvent fournir, ou quand le débit par partition est le facteur limitant. Attention : ajouter des partitions modifie la correspondance clé-partition pour les nouveaux enregistrements, donc l'ordre pour une clé peut être rompu lors du changement. Planifiez le nombre de partitions en amont lorsque l'ordre est important.
17. Comment les données sont-elles conservées, et qu'est-ce que la compaction de log ?
Par défaut, Kafka supprime les anciens segments selon le temps ou la taille (retention.ms, retention.bytes). Avec la compaction de log, Kafka conserve au moins la dernière valeur pour chaque clé, ce qui convient à un changelog ou à un topic de type table. Une valeur nulle (un tombstone) marque une clé pour suppression.
18. Que se passe-t-il si un broker tombe en panne ?
Les partitions dont ce broker était leader élisent de nouveaux leaders parmi l'ISR. Les clients rafraîchissent les métadonnées et continuent. S'il n'y a aucune réplique synchronisée disponible, la partition est indisponible, sauf si vous autorisez l'élection de leader non propre, ce qui risque une perte de données.
19. Comment sécuriser un cluster Kafka ?
TLS pour le chiffrement en transit, SASL (comme SCRAM ou OAuth) ou mTLS pour l'authentification, des ACL pour l'autorisation sur les topics et les groupes, et des contrôles réseau. Chiffrez les champs sensibles au niveau de l'application si nécessaire.
20. Comment surveiller Kafka ?
Les signaux clés sont le lag des consommateurs, les partitions sous-répliquées, les partitions hors ligne, la latence des requêtes, l'utilisation du disque, ainsi que les taux de réduction et d'expansion de l'ISR, collectés via les métriques JMX et des outils comme Prometheus et Grafana.
Questions de conception
21. Quand choisiriez-vous Kafka plutôt qu'une file de messages comme RabbitMQ ou SQS ?
Choisissez Kafka lorsque vous avez besoin d'un débit élevé, de rejouer des événements passés, de plusieurs consommateurs indépendants du même flux ou de traitement de flux. Choisissez une file traditionnelle pour le routage par message, les files de tâches simples, ou lorsque vous ne voulez pas gérer les partitions.
22. Concevez un pipeline d'événements de commandes.
« Les commandes arrivent dans un topic orders avec l'ID de commande comme clé, afin que les événements d'une même commande restent ordonnés. J'utiliserais au moins trois brokers, un facteur de réplication de 3, acks=all et des producteurs idempotents. Les consommateurs pour la facturation, les stocks et l'analytique utilisent chacun leur propre groupe. Les écritures de facturation sont idempotentes par ID de commande, les enregistrements en échec partent vers un topic dead-letter, et je surveillerais le lag par groupe. Je choisirais le nombre de partitions en fonction du débit de pointe et du nombre de consommateurs prévu, avec une marge de croissance. »
Comment se préparer
Si vous le pouvez, lancez un Kafka en local, écrivez un producer et un consumer group, arrêtez un consumer et observez le rebalance. Cassez quelque chose volontairement, par exemple un consumer lent, et regardez le lag. Préparez une histoire concrète sur un problème de pipeline de données que vous avez résolu. Pour les sujets connexes, consultez nos guides sur Databricks et les entretiens de system design.
Entraînez-vous à expliquer les garanties de livraison à voix haute, car c'est là que les réponses deviennent floues. Un entretien simulé et une transcription vous montreront où. Respectez les règles de l'employeur concernant les outils d'IA lors de tout entretien en direct.
Entraînez-vous aux réponses d'entretien Kafka avec YesToTheOffer
Faites un entretien technique simulé, expliquez les garanties de livraison à voix haute et révisez votre transcription ensuite. 30 minutes gratuites, sans abonnement.
