Départ · Dakar
Arrivée
W
MD
I
ÉA
I
TK
C
IA
O
ER
D
R
E
SÀ l’heure
Il fait circuler les événements entre les systèmes sans en perdre un seul, même quand tout arrive en même temps.
L’ingénieur flux d’événements conçoit les systèmes où chaque fait métier (commande passée, paiement reçu, colis livré) devient un événement publié, conservé et consommé par d’autres services. Apache Kafka en est la pièce centrale.
Il intervient là où le volume ou le découplage l’exigent : logistique, télécoms, plateformes de paiement, suivi d’activité en temps réel, synchronisation entre applications.
Son travail commence après le choix de Kafka : découper les sujets (topics) et leurs partitions, garantir qu’un message traité deux fois n’a pas deux effets, répliquer les données entre régions, et donner aux équipes des producteurs et des consommateurs qu’elles savent faire évoluer. Depuis Kafka 4.0, ZooKeeper a disparu : le cluster tourne en mode KRaft, ce qui simplifie l’exploitation sans la rendre anodine.
Modéliser les événements, les sujets et leurs partitions : par exemple, un sujet par domaine (commandes, livraisons, notifications), partitionné par identifiant de client pour garder l’ordre des événements d’un même compte.
Écrire les services qui publient et traitent les événements : par exemple, un consommateur Spring Kafka qui met à jour le stock à chaque commande, dans un groupe de consommateurs qui se répartit les partitions.
Garantir qu’un message livré deux fois n’a pas d’effet double : par exemple, un producteur idempotent, une clé d’événement unique vérifiée avant chaque écriture, et une table de sortie (outbox) remplie dans la même transaction que la commande, puis relayée vers Kafka par Debezium.
Calculer au fil de l’eau sans attendre la nuit : par exemple, une application Kafka Streams qui agrège les ventes par boutique et par heure, et signale une boutique dont les paiements échouent en série.
Garder les données disponibles si une région tombe : par exemple, un cluster en Europe et un en Afrique synchronisés par MirrorMaker 2, avec une bascule des consommateurs testée en exercice, et non découverte le jour de la panne.
Tenir la plateforme et ses contrats de données : par exemple, un registre de schémas Avro qui refuse une modification incompatible, un sujet de rebut (dead letter) pour les messages invalides et une alerte sur le retard de chaque groupe de consommateurs.
De la base vers le haut : ce qu'il manie chaque jour.
Langages
Plateforme
Données
Clients et frameworks
Exploitation
Supervision
Un message peut arriver en retard, deux fois ou dans le désordre : il conçoit chaque consommateur pour que cela ne change rien.
Un schéma modifié sans précaution casse tous les consommateurs d’un coup, parfois dans une autre équipe.
Quand les événements s’accumulent un jour de paie, il lit le retard des partitions et agit sans précipitation.
Sa plateforme sert des équipes qu’il ne dirige pas, et il doit la rendre simple à utiliser pour elles.
0 à 2 ans
Il écrit des producteurs et des consommateurs sur des sujets déjà définis, ajoute des tests avec Testcontainers et apprend à lire le retard d’un groupe de consommateurs.
3 à 5 ans
Il conçoit les flux d’un domaine, ses schémas et sa stratégie de partitionnement, met en place l’idempotence et suit la plateforme en production.
6 ans et plus
Il dimensionne et exploite la plateforme pour toute l’entreprise, organise la réplication entre régions, fixe les règles de nommage et d’évolution des schémas et forme les équipes.
Master ou école d’ingénieurs en informatique, après plusieurs années de développement backend ou de data engineering. Les certifications Confluent existent, mais un flux en production, avec sa réplication et ses tests de bascule, en dit plus.
Architecte logiciel, ingénieur plateforme, data engineer, architecte cloud.
Vous ne trouvez pas votre métier ?Candidature spontanée
