Architecte data streaming Kafka : schémas, CDC et rejeu

Un entretien d'architecte data streaming ne ressemble pas à celui d'un data engineer Kafka. Le développeur fait tourner un flux. L'architecte décide quels événements existent, qui en est propriétaire, comment leurs schémas évoluent et ce qui se passe le jour où il faut tout rejouer. Sur Free-Work, les missions qui demandent ce profil viennent souvent de la banque : socle d'échange entre applications, migration de ZooKeeper vers KRaft, chiffrement des données en transit et au repos.

Beaucoup de CV d'architecte citent Kafka, Confluent et Debezium parce que la personne a codé des producteurs et des consommateurs. Le niveau architecte se voit ailleurs. Le candidat explique pourquoi il a refusé une double écriture, comment il a fait retirer un champ sans casser quinze consommateurs, quelle clé de partition il a imposée et ce que son plan de reprise prévoit pour les offsets sur le site de secours.

Le lag et les watermarks relèvent plutôt de l'entretien d'un data engineer. L'architecte arrive rarement sur une page blanche : interrogez le manager sur le nombre d'équipes qui consomment déjà les topics et sur l'existence d'un registre de schémas.

Les briques qu'un architecte streaming assemble

Apache Kafka et KRaft

Le journal d'événements partagé sur lequel tout repose. Depuis Kafka 4.0, ZooKeeper a disparu et le cluster fonctionne uniquement en mode KRaft, ce qui explique les missions de migration en cours. L'architecte en fixe les règles d'usage : découpage des topics, clés de partition, rétention.

Schema Registry et contrats de données

Le registre stocke les schémas Avro, Protobuf ou JSON des événements et refuse les changements incompatibles selon le mode choisi. Autour du schéma, le contrat ajoute le propriétaire, le sens des champs et les règles de qualité. C'est ici que l'architecte évite qu'une équipe en casse quinze autres.

Debezium et pattern outbox

Debezium lit le journal de transactions d'une base (PostgreSQL, Oracle, SQL Server, MySQL) et publie chaque changement dans Kafka. Avec le pattern outbox, l'application écrit l'événement dans une table dédiée dans la même transaction que la donnée métier. Demandez quand le candidat choisit l'un ou l'autre.

Flink et Kafka Streams

Les moteurs qui transforment, joignent et agrègent les flux. L'architecte n'en règle pas chaque paramètre, mais il décide lequel employer, où placer l'état et comment republier des événements métier propres à partir de flux techniques.

Event sourcing et CQRS

Deux patterns où l'état d'un service est reconstruit à partir de la suite de ses événements, avec des vues de lecture séparées. Utiles pour l'audit ou un grand livre, coûteux ailleurs. Un bon architecte sait dire quand il les déconseille.

Sagas et orchestration

Pour garder la cohérence d'un processus qui traverse plusieurs services sans transaction globale, on enchaîne des étapes avec des actions de compensation. La saga peut être chorégraphiée par les événements ou pilotée par un orchestrateur comme Temporal.

Réplication multi-site

MirrorMaker 2, ou Cluster Linking chez Confluent, recopie les topics vers un autre cluster pour la reprise après sinistre ou le partage entre régions. La réplication est asynchrone, ce qui a des conséquences sur la perte de données acceptable et sur la reprise des consommateurs.

Lakehouse et Iceberg

Les événements finissent souvent aussi en tables Apache Iceberg pour l'analyse, via Kafka Connect, Flink ou Tableflow chez Confluent. L'architecte arbitre la fraîcheur, le nombre de petits fichiers et l'évolution des schémas jusqu'aux tables.

Offres managées

Confluent Cloud, Amazon MSK et Azure Event Hubs avec son API Kafka évitent d'opérer les brokers. Elles diffèrent par les fonctions supportées, le modèle de coût et l'hébergement. Le choix fait partie du poste, surtout quand la souveraineté des données entre en jeu.

Le poste se rencontre surtout dans les grands comptes et chez les ESN qui les accompagnent, quand plusieurs dizaines d'applications échangent déjà par Kafka ou vont le faire. Chez un client final, l'architecte écrit les règles de la plateforme d'événements et les fait appliquer dans la durée. En ESN, la mission porte souvent sur un sujet précis : sortie de ZooKeeper, mise en place d'un Schema Registry, remplacement d'échanges par fichiers ou d'une double écriture par du CDC. Le titre varie selon les annonces, entre architecte Kafka, architecte event-driven et data architect streaming. Certains profils viennent de l'intégration applicative (ESB, MOM), d'autres de la data. Les deux chemins mènent au poste, à condition de maîtriser les contrats de schémas et la reprise.

Les choix qu'un architecte data streaming doit savoir justifier

• Modélisation des événements et des topics
• Contrats de schémas et compatibilité
• Intégration des bases : CDC et outbox
• Cohérence entre services et garanties de livraison
• Rétention, rejeu et reprise multi-site
• Gouvernance, sécurité et coût de la plateforme

Cinq décisions d'architecture à faire expliquer

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.

1. Question 1 · senior

   Une équipe veut publier un seul topic « client-modifié » qui transporte la fiche client complète à chaque changement. Une autre préfère un événement par fait métier, comme « adresse changée » ou « contrat résilié ». Comment tranchez-vous ?

   Une bonne réponseLe candidat distingue deux usages. Un topic d'état, compacté et clé par identifiant client, sert les consommateurs qui veulent la dernière version de la fiche. Des événements métier servent ceux qui doivent réagir à un fait précis, comme une résiliation. Souvent les deux coexistent, avec un propriétaire unique côté domaine client. Il regarde qui consomme, la taille des messages et la diffusion des données personnelles, qu'une fiche complète recopie partout.

   Signal d'alerte« Un topic par table, comme dans la base », appliqué par défaut. Ou un grand topic « events » qui mélange tous les types sans règle. Aucune question sur les consommateurs.

2. Question 2 · senior

   Vous avez 200 topics et trente équipes. Comment organisez-vous les règles de compatibilité des schémas, et que faites-vous quand un changement cassant devient inévitable ?

   Une bonne réponseUn mode de compatibilité fixé par sujet dans le Schema Registry : BACKWARD par défaut, qui impose de mettre à jour les consommateurs avant les producteurs, et un mode transitif sur les topics conservés longtemps ou rejoués. Le contrôle de compatibilité tourne dans la CI avant le déploiement. Pour un changement cassant, un nouveau topic versionné (commandes.v2) alimenté en parallèle pendant une période annoncée, puis le retrait de l'ancien à une date connue des consommateurs.

   Signal d'alerteLe mode NONE « pour aller plus vite », du JSON sans schéma, ou « on prévient les équipes par mail ». Ignorer que la compatibilité non transitive ne vérifie que la version précédente.

3. Question 3 · confirmé

   Un service enregistre une commande en base, puis publie l'événement dans Kafka. De temps en temps, l'événement manque, ou il part pour une commande dont la transaction a échoué. Que changez-vous dans l'architecture ?

   Une bonne réponseIl reconnaît la double écriture (dual write) : la base et Kafka ne sont pas mises à jour de façon atomique. Il propose le pattern outbox, avec l'événement écrit dans une table outbox dans la même transaction que la commande, puis publié par Debezium qui lit le journal de la base. À défaut, une capture des changements directement sur les tables métier quand on ne peut pas toucher à l'application. Les consommateurs restent idempotents, puisque la livraison se fait au moins une fois.

   Signal d'alerte« On ajoute des relances. » Une transaction distribuée XA entre la base et Kafka. Ou « les transactions Kafka règlent le problème », alors qu'elles ne couvrent pas la base de données.

4. Question 4 · senior

   Une souscription traverse quatre services : contrat, paiement, documents, notification. Le paiement échoue alors que le contrat est déjà créé. Comment gardez-vous le système cohérent sans transaction globale ?

   Une bonne réponseUne saga. Chaque étape publie son résultat, et un échec déclenche des actions de compensation, ici l'annulation du contrat. Le candidat compare la chorégraphie, où chaque service réagit aux événements des autres, et l'orchestration, où un composant pilote le processus (un moteur comme Temporal ou un process manager maison). Il prévoit des clés d'idempotence, des délais d'expiration et un état intermédiaire visible, du type « en attente de paiement », que le métier accepte.

   Signal d'alerteUn commit en deux phases entre services, ou « on fait un rollback » sans dire comment on annule ce qui est déjà publié. Aucune prise en compte des messages reçus deux fois.

5. Question 5 · senior

   Pendant dix jours, un bug a faussé les événements de solde publiés par un service. Six applications les ont déjà consommés. Comment corrigez-vous ?

   Une bonne réponseOn ne réécrit pas l'historique d'un topic. Deux options : publier des événements de correction que les consommateurs savent appliquer, ou recalculer à partir des événements sources conservés (topic brut à longue rétention, stockage hiérarchisé ou archive dans le lakehouse) vers une nouvelle version du topic, puis basculer les consommateurs. Il vérifie avec chaque équipe les effets de bord d'un retraitement, comme des e-mails renvoyés, et rappelle que la politique de rétention se décide avant l'incident.

   Signal d'alerte« On supprime les messages faux dans le topic. » Ou une remise à zéro des offsets de tous les consommateurs sans regarder ce que chacun déclenche.

Recruter un architecte Kafka : les questions des recruteurs

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.