Gestion Scolaire — Architecture Microservices
Développeur solo•Projet Personnel•2026
Reconstruction en microservices de la plateforme de gestion scolaire : 12 services Spring Boot indépendants orchestrés via Eureka, exposés derrière une Spring Cloud Gateway unique avec authentification JWT. Couvre utilisateurs/rôles, structure académique, notes, présences et messagerie interne, avec événements Kafka et reporting analytique en CQRS sur PostgreSQL.
Technologies
Contexte & Objectif
Le School Management System original (voir le projet séparé sur cette page) était un monolithe Spring Boot unique. Ce projet reconstruit le même domaine métier — étudiants, enseignants, structure académique, notes, présences, messagerie — sous forme de plateforme microservices indépendante, pour travailler les problèmes d'architecture qu'un monolithe ne force pas à résoudre.
Objectifs techniques :
- Chaque domaine (identité, structure académique, évaluation, présences, reporting…) porté par son propre service avec sa propre base de données, déployable indépendamment
- Un point d'entrée unique et stable pour les clients, quels que soient les déplacements ou changements internes des services
- Communication asynchrone et découplée entre services plutôt que des appels synchrones directs qui propagent les pannes dans tout le système
Architecture & Choix Techniques
12 services Spring Boot 3 indépendants enregistrés auprès d'un registre de services Eureka et exposés derrière une Spring Cloud Gateway unique (port 9000) qui gère le routage et l'authentification JWT — les clients ne parlent qu'à la Gateway, jamais directement à un service, si bien qu'un déplacement ou un découpage interne ne casse aucune intégration côté client (documenté explicitement pour les consommateurs frontend dans le guide d'intégration API de la plateforme).
Les services communiquent de façon asynchrone via Apache Kafka pour tout ce qui n'exige pas de réponse immédiate — découplant producteurs et consommateurs, empêchant la lenteur d'un service de se propager en cascade sur un autre. Le Report Service applique spécifiquement le pattern CQRS (Command Query Responsibility Segregation) pour séparer ses chemins de lecture et d'écriture, les requêtes analytiques/reporting ayant des besoins de performance très différents des écritures transactionnelles du reste du système. Resilience4j (circuit breakers, rate limiting) et Spring Boot Actuator + Micrometer complètent la couche tolérance aux pannes et observabilité.
Le Processus
Découpage en services — le domaine du monolithe a été scindé selon des bounded contexts : Identity (8084), Academic Structure (8086), Evaluation (8089), Attendance (8090), plus Report et d'autres, chacun possédant sa propre base PostgreSQL (10 bases au total) plutôt que d'en partager une — la version plus exigeante mais plus honnête de « services indépendants ».
Infrastructure & données — Eureka et la Gateway sont les premiers services démarrés, suivis de Kafka/Zookeeper via un docker-compose dédié, puis les migrations de schéma propres à chaque service sur sa base.
Déploiement — chaque service est conteneurisé (Docker + Docker Compose), construit avec Maven, et expose santé/métriques via Actuator pour l'orchestration et le monitoring.
Défis Techniques & Solutions
Défi — 12 services, c'est 12 endroits où une intégration cliente peut casser silencieusement à mesure que le système évolue. Solution : la Gateway est le seul contrat que les clients voient jamais ; un guide d'intégration API dédié le documente explicitement (« jamais d'appel direct aux services internes, jamais de port de service en dur ») pour que les équipes frontend restent isolées des réorganisations internes.
Défi — coordonner 10 bases PostgreSQL séparées, Kafka/Zookeeper et 12 services dans le bon ordre de démarrage en développement local. Solution : l'infrastructure (broker Kafka) est isolée dans son propre docker-compose, séparé des services applicatifs, et Eureka + la Gateway sont démarrés en premier pour que chaque service ait un registre à rejoindre avant de servir du trafic.
Résultats & Impact
- 12 services Spring Boot déployables indépendamment derrière un point d'entrée Gateway unique, avec authentification JWT imposée en bordure
- Communication événementielle via Kafka remplaçant les appels synchrones directs entre services
- Service de reporting en CQRS, séparant les lectures analytiques des écritures transactionnelles
- Stack d'observabilité complète (Actuator + Micrometer) et patterns de résilience (circuit breakers / rate limiting Resilience4j) intégrés dès le départ plutôt qu'ajoutés après coup