Presque toutes les offres de développeur Java Kafka décrivent la même pile : Java 17 ou 21, Spring Boot avec Spring for Apache Kafka, parfois Kafka Connect ou Kafka Streams, une base relationnelle ou MongoDB. Le développeur ne gère pas le cluster, qui revient à l'équipe plateforme ou à un administrateur Kafka. Il conçoit les topics de son application, le format des messages, les clés de partitionnement et le comportement en cas d'erreur.
Un CV qui cite Kafka dit peu de chose. Beaucoup de développeurs ont branché un @KafkaListener sans jamais traiter un rééquilibrage, un message empoisonné ou un doublon. Pour situer un profil, demandez ce qui se passe quand le traitement d'un message échoue, quand l'application redémarre au milieu d'un lot, et comment un événement part après une écriture en base.
Le niveau senior se voit sur les garanties. Le producteur idempotent est activé par défaut depuis Kafka 3.0 et les transactions permettent l'exactly-once entre topics, mais aucun des deux ne protège une écriture en base ou un appel externe. Un senior le dit de lui-même et propose un outbox ou un consommateur idempotent. Le PDF couvre six axes et un cas de 20 minutes.
Les outils Kafka d'un développeur Java
Client Java Kafka
La bibliothèque officielle, en version 4. Le producteur choisit la partition à partir de la clé, le consommateur lit ses partitions et valide sa position, l'offset. Les réglages acks, max.poll.records et max.poll.interval.ms expliquent une bonne partie des incidents.
Spring for Apache Kafka
L'intégration Spring, en version 4.1 avec Spring Boot 4.1. On y trouve @KafkaListener, KafkaTemplate, les conteneurs de consommateurs, le DefaultErrorHandler et les topics de nouvelle tentative. Beaucoup de comportements par défaut, comme le moment où l'offset est validé, viennent de cette couche et non du client.
Kafka Streams
La bibliothèque Java de traitement de flux, embarquée dans l'application. Elle gère agrégations, jointures et fenêtres avec des magasins d'état locaux sauvegardés dans des topics. Le mode exactly_once_v2 donne une garantie de bout en bout tant que tout reste dans Kafka.
Schema Registry et Avro
Le registre de schémas (Confluent, Apicurio ou Karapace) stocke le format de chaque message et contrôle sa compatibilité à chaque évolution. Avro est le plus courant, Protobuf et JSON Schema existent aussi. Une évolution mal faite casse les consommateurs en production.
Kafka Connect et Debezium
Connect déplace les données entre Kafka et d'autres systèmes (bases, stockage objet, moteurs de recherche) sans code applicatif. Debezium, le connecteur de capture des changements le plus connu, sert aussi à publier une table outbox.
Patterns outbox et saga
L'outbox écrit l'événement dans la même transaction que la donnée métier, puis le publie. La saga enchaîne des étapes locales avec des compensations quand une étape échoue. Les deux remplacent une transaction commune entre une base et Kafka, qui n'existe pas.
Testcontainers et EmbeddedKafka
Pour les tests d'intégration, un vrai broker dans un conteneur avec Testcontainers, ou le broker embarqué de spring-kafka-test. TopologyTestDriver teste une topologie Kafka Streams sans broker.
Supervision des consommateurs
Le retard des consommateurs (consumer lag) par partition, les rééquilibrages, les messages envoyés en topic d'erreurs. Le développeur expose ces métriques avec Micrometer et doit savoir les lire, même si l'équipe plateforme tient les tableaux de bord.
Le travail mêle deux choses. D'un côté, ajouter des événements à une application : publier une commande validée, réagir à un paiement, remplacer des appels REST en chaîne entre services. De l'autre, brancher l'application sur un bus d'intégration où Kafka relie des dizaines d'applications, avec Kafka Connect et des formats fixés par une équipe d'architecture. Le cluster est tenu par un administrateur Kafka ou par un service managé (Confluent Cloud, Amazon MSK, Azure Event Hubs). Kafka 4.0 a retiré ZooKeeper et rendu disponible un nouveau protocole de groupe de consommateurs, qui change le déroulement des rééquilibrages. La certification Confluent Certified Developer for Apache Kafka (CCDAK) atteste les bases du client et de Kafka Streams.
Ce qu'un développeur Java Kafka doit savoir faire
- Producteurs, partitionnement et ordre des messages
- Consommateurs, offsets et rééquilibrages
- Erreurs, nouvelles tentatives et topic d'erreurs
- Idempotence, transactions et exactly-once
- Schémas et évolution des formats
- Kafka Streams et tests
Cinq questions sur les offsets, l'ordre et les doublons
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Votre consommateur valide l'offset, puis plante pendant l'écriture en base. Que devient le message ? Et si l'ordre est inversé ?
Une bonne réponseOffset validé avant le traitement : le message est perdu au redémarrage, c'est une livraison au plus une fois. Validé après : le message est retraité, c'est une livraison au moins une fois, avec des doublons possibles. La bonne pratique est de valider après le traitement et de rendre celui-ci idempotent (clé métier unique, upsert, table des messages déjà traités). Avec Spring Kafka, il sait que enable.auto.commit est désactivé et que le conteneur valide par défaut après le traitement du lot (AckMode BATCH).
Signal d'alerte« Kafka garantit que chaque message est traité une seule fois », ou l'auto-commit activé sans savoir quand l'offset avance.
Question 2 · confirmé
Les événements d'une même commande doivent être traités dans l'ordre. Comment le garantissez-vous du producteur au consommateur ?
Une bonne réponseL'ordre n'existe qu'à l'intérieur d'une partition : tous les événements d'une commande portent la même clé, l'identifiant de commande, pour aller dans la même partition. Côté producteur, l'idempotence, activée par défaut, garde l'ordre malgré les nouvelles tentatives. Côté consommateur, une partition n'est lue que par un consommateur du groupe, et un traitement parallèle à l'intérieur doit regrouper par clé. Il sait qu'ajouter des partitions à un topic déplace certaines clés.
Signal d'alerteUn topic à une seule partition pour tout, ou « Kafka garde l'ordre global du topic ».
Question 3 · confirmé
Un message mal formé fait planter votre @KafkaListener en boucle et bloque la partition. Comment traitez-vous ce cas ?
Une bonne réponseUn ErrorHandlingDeserializer pour que l'erreur de désérialisation n'arrête pas le conteneur, un DefaultErrorHandler avec un nombre limité de tentatives et un délai entre elles, et un DeadLetterPublishingRecoverer qui publie le message sur un topic d'erreurs avec les en-têtes de l'exception. Les exceptions non rejouables, comme une erreur de validation, partent tout de suite vers ce topic. Il prévoit qui le relit et comment rejouer un message corrigé.
Signal d'alerteUn try/catch qui journalise et avale l'erreur sans trace exploitable, ou des tentatives infinies qui bloquent la partition.
Question 4 · senior
Votre service enregistre une commande en base puis publie l'événement « commande créée ». Que se passe-t-il si Kafka est indisponible entre les deux ?
Une bonne réponseLa base et Kafka n'ont pas de transaction commune : soit la commande existe sans événement, soit un événement part pour une commande dont l'écriture a été annulée. Le pattern outbox règle le problème : l'événement est inséré dans une table outbox, dans la même transaction que la commande, puis publié par un relais ou par Debezium qui lit le journal de la base. Les consommateurs restent idempotents, car le relais peut publier deux fois.
Signal d'alerteEnvoyer dans la méthode @Transactional en pensant que tout sera annulé ensemble, ou improviser une transaction distribuée entre la base et Kafka.
Question 5 · confirmé
Vous devez ajouter un champ à un événement Avro lu par six équipes. Comment procédez-vous sans casser personne ?
Une bonne réponseIl vérifie le mode de compatibilité du sujet dans le registre de schémas (BACKWARD par défaut dans le Schema Registry de Confluent). Un champ ajouté avec une valeur par défaut reste compatible ; sans valeur par défaut, les anciens messages ne se lisent plus avec le nouveau schéma. En mode BACKWARD, les consommateurs passent au nouveau schéma avant les producteurs, et la compatibilité est testée dans la CI avec le plugin Maven ou Gradle du registre. Un vrai changement de sens passe par une nouvelle version d'événement ou un nouveau topic.
Signal d'alerteModifier le schéma et prévenir les équipes par e-mail, ou désactiver la vérification de compatibilité.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Questions fréquentes avant de recruter un développeur Java Kafka
Le développeur Java Kafka doit-il savoir administrer le cluster ?
Non, mais il doit comprendre ce que l'administrateur règle et pourquoi cela touche son code : nombre de partitions, facteur de réplication, min.insync.replicas, rétention, ACL. Il crée rarement les topics lui-même en production, il les demande avec les bons paramètres. Sur un poste où l'équipe gère aussi son propre cluster, ajoutez des questions d'exploitation : réplication, mise à jour des brokers, supervision. C'est un autre profil, plus proche de l'administrateur Kafka.
Que vaut la certification CCDAK de Confluent pour ce poste ?
Elle montre que la personne connaît le client Java, les garanties de livraison, Kafka Streams et le registre de schémas. Elle repose sur un QCM et ne dit rien de la conduite d'un incident réel. Utilisez-la comme point de départ : demandez un message empoisonné géré en production, un rejeu mené sur un groupe, une évolution de schéma passée sans casse. Sans exemple concret, la certification reste une base théorique.
Kafka Streams est-il indispensable sur un CV ?
Seulement si le poste fait des traitements avec état : agrégations, jointures entre topics, fenêtres de temps. Beaucoup de postes se limitent à produire et à consommer avec Spring Kafka, et la maîtrise des offsets, des erreurs et de l'idempotence compte alors davantage. Si Kafka Streams est demandé, vérifiez la compréhension des magasins d'état et de leur reprise, qui sépare un usage réel d'un tutoriel suivi.
Quel exercice donner à un développeur Java Kafka pendant l'entretien ?
Un test technique court, fait en direct, vaut mieux qu'un projet à rendre. Donnez un consommateur Spring Kafka qui valide l'offset avant d'écrire en base et n'a aucune gestion d'erreur. La personne corrige, ajoute un topic d'erreurs et rend l'écriture idempotente, en commentant à voix haute. En 45 minutes, vous voyez sa compréhension des offsets, des doublons et des erreurs, qui sont au centre du poste.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
