Le problème à résoudre
Le traitement des transactions est synchrone et couplé : un pic d’activité (fin de mois, promotion, salaire) sature le système et provoque des lenteurs ou des pertes. Les composants se bloquent mutuellement.
La promesse pour la direction
Votre développeur conçoit des architectures événementielles : les transactions sont traitées de manière asynchrone via des files de messages, absorbant les pics, découplant les services et garantissant qu’aucun événement n’est perdu.
Ce que le parcours débloque
Absorption (file)
Résistance aux pics
Découplé
Couplage entre services
Nulle
Perte d’événements
Le cadre
| Élément | Valeur |
|---|---|
| Profil cible | Développeur orienté données / back-end |
| Prérequis | SQL, programmation, APIs |
| Durée | 6 mois (accélérateur) |
| Format | Blended · 70 % de pratique |
Pile technique maîtrisée à l’issue
Apache Kafka · RabbitMQ · Kafka Streams · Flink · Avro · PostgreSQL · Debezium
Les jalons
Une trajectoire pour un collaborateur déjà en poste. Chaque mois est validé par un livrable et un critère d’acceptation écrit à l’avance.
| Mois | Thème | Atelier | Validation |
|---|---|---|---|
| M1 | Du synchrone à l’asynchrone Découplage | Identifier les traitements à rendre asynchrones | ✔ Cas d’usage asynchrones identifiés |
| M2 | Brokers de messages Kafka / RabbitMQ | Mettre en place un bus d’événements | ✔ Bus de messages opérationnel |
| M3 | Produ cteurs/consommateurs Patterns événementiels | Produire et consommer des événements fiables | ✔ Aucun événement perdu |
| M4 | Résilience Reprise & idempotence | Gérer les pannes et les rejeux | ✔ Traitement idempotent garanti |
| M5 | Event sourcing / CQRS Patterns avancés | Appliquer event sourcing à un domaine | ✔ Historique d’événements exploitable |
| M6 | Projet événementiel Architecture réelle | Traiter un flux transactionnel réel | ✔ Soutenance + pic de charge absorbé |