Cas pratiques Architecture Microservices

Contexte : Après migration, 8 microservices exposent chacun leur propre API REST. Les clients frontend font jusqu'à 12 appels pour afficher une seule page. Le Problème : Chatty interface, gestion de l'authentification dupliquée dans chaque service, CORS à gérer partout, et les clients connaissent l'adresse interne de chaque service. Contraintes : Concevoir une API Gateway centralisant le routage, l'authentification JWT, le rate limiting et l'agrégation de réponses. Implémenter le pattern Backend for Frontend (BFF) si pertinent. Gérer les cas de service indisponible (circuit breaker). Livrable attendu : Architecture de l'API Gateway avec les règles de routage, la stratégie d'authentification, la gestion des erreurs et les décisions BFF vs Gateway unique.

Contexte : Avec 20 microservices en production, les appels inter-services échouent de manière intermittente. Une panne de 30 secondes sur le User Service provoque des erreurs en cascade sur 8 autres services. Le Problème : Absence de retry intelligent, de circuit breaker et de timeout cohérent entre services. Chaque équipe implémente sa propre logique de résilience de manière inconsistante. Contraintes : Évaluer l'adoption d'un service mesh (Istio ou Linkerd). Implémenter circuit breaker, retry avec backoff exponentiel et timeout par appel. Définir les politiques de résilience globales sans modifier le code applicatif. Gérer les bulkheads pour isoler les pannes. Livrable attendu : Architecture de résilience avec les policies de circuit breaker par service, la configuration du service mesh et les tests de chaos engineering pour valider la stratégie.

Contexte : Le monolithe utilise une seule base PostgreSQL avec 120 tables. Après extraction des services, trois microservices (Orders, Inventory, Billing) partagent encore la même base et font des JOIN cross-domaines. Le Problème : Ce pattern « Shared Database » annule les bénéfices des microservices : couplage fort, impossible de changer le schéma d'un service sans impacter les autres. Contraintes : Identifier et éliminer les JOIN cross-domaines. Proposer une stratégie de décomposition (une DB par service). Gérer la duplication de données nécessaire. Mettre en place la synchronisation via événements. Livrable attendu : Plan de décomposition de la base incluant les tables concernées, la stratégie de migration des données, et le schéma de synchronisation par événements.

Contexte : Le monolithe avait un seul fichier de configuration. Après migration, 15 microservices ont chacun leur configuration, et des secrets (clés API, mots de passe DB) sont en dur dans le code ou dans des fichiers committés. Le Problème : Rotation des secrets impossible sans redéploiement, configuration divergente entre environnements, risque de fuite de secrets dans les logs ou les dépôts Git. Contraintes : Implémenter une stratégie de gestion de configuration centralisée (Vault ou AWS Secrets Manager). Externaliser toutes les configurations par environnement. Mettre en place la rotation automatique des secrets. Assurer l'accès au principe de moindre privilège. Livrable attendu : Architecture de gestion de configuration et secrets avec le modèle d'accès par service, la stratégie de rotation et l'intégration dans le pipeline CI/CD.

Contexte : Un processus de commande implique 4 microservices : Order Service, Payment Service, Inventory Service, Shipping Service. Une transaction ACID globale n'est plus possible. Le Problème : Si le paiement réussit mais que le stock est indisponible, la commande doit être annulée. Sans transaction distribuée, les données deviennent incohérentes. Extrait de la situation actuelle : begin_transaction() create_order() charge_payment() reserve_inventory() create_shipment() commit() Contraintes : Implémenter le pattern Saga (choreography ou orchestration). Définir les compensating transactions pour chaque étape. Gérer les cas de timeout et de panne partielle. Livrable attendu : Modéliser le flux Saga complet avec tous les scénarios d'échec et leurs actions compensatoires associées.

Contexte : Une plateforme e-commerce monolithique gère en un seul déploiement : catalogue produits, panier, commandes, paiement, livraison, notifications et gestion des utilisateurs. Le Problème : L'équipe veut migrer vers les microservices mais ne sait pas comment découper le monolithe sans créer un « distributed monolith ». Contraintes : Appliquer le Domain-Driven Design pour identifier les Bounded Contexts. Définir les limites de chaque contexte (ubiquitous language, agrégats). Cartographier les dépendances entre contextes. Justifier pourquoi certains domaines doivent rester couplés ou être séparés. Livrable attendu : Produire une Context Map complète avec les relations entre Bounded Contexts (Partnership, Customer-Supplier, Anti-Corruption Layer) et une proposition de découpage en services autonomes.

Contexte : Un ERP monolithique contient un module de facturation critique avec 50 000 lignes de code. Une réécriture complète est trop risquée. Le Problème : L'équipe doit migrer progressivement le module vers un microservice sans interruption de service et sans régression fonctionnelle. Contraintes : Appliquer le pattern Strangler Fig (façade de routage). Définir les étapes de bascule progressive (feature flags ou routing rules). Gérer la coexistence de l'ancien et du nouveau code. Assurer la parité fonctionnelle avant chaque bascule. Livrable attendu : Concevoir le plan de migration étape par étape avec la stratégie de routage, les critères de bascule et le plan de rollback en cas d'incident.

Contexte : Les microservices communiquent via appels REST synchrones en chaîne. Order Service appelle Payment Service qui appelle Inventory Service qui appelle Notification Service. En cas de lenteur, des timeouts en cascade paralysent le système. Le Problème : Couplage temporel fort, disponibilité du système = disponibilité du service le plus lent, absence de résilience. Contraintes : Migrer vers une architecture event-driven avec Kafka. Définir les événements métier (OrderCreated, PaymentProcessed, etc.). Gérer l'idempotence des consommateurs. Assurer l'ordre des événements critiques. Livrable attendu : Schéma de l'architecture event-driven avec la définition des topics Kafka, la stratégie de partitionnement, la gestion des erreurs (dead letter queue) et le traitement des événements dupliqués.

Contexte : Après migration vers 12 microservices, une requête utilisateur traverse en moyenne 5 services. Un bug de production prend 4 heures à diagnostiquer car les logs sont éparpillés et sans corrélation. Le Problème : Sans observabilité distribuée, le debugging en production est quasi impossible. Les équipes ne savent pas quel service est responsable d'une latence ou d'une erreur. Contraintes : Implémenter le distributed tracing (OpenTelemetry + Jaeger ou Zipkin). Centraliser les logs avec correlation ID. Mettre en place des métriques par service (RED method). Créer des alertes intelligentes. Livrable attendu : Architecture d'observabilité complète avec la stratégie d'instrumentation des services, la propagation du trace context et un tableau de bord de monitoring adapté.

Contexte : Le Payment Service traite 10 000 transactions par heure. Une mise à jour récente a introduit un bug qui a causé 2 heures d'interruption lors d'un déploiement classique. Le Problème : Les déploiements sont risqués, les rollbacks sont lents (15 minutes) et il est impossible de tester en production sur un sous-ensemble d'utilisateurs. Contraintes : Implémenter une stratégie Blue/Green pour les services critiques. Mettre en place un déploiement Canary avec routage progressif (1% → 10% → 50% → 100%). Définir les critères d'automatisation de la promotion ou du rollback. Assurer la compatibilité descendante des API pendant la coexistence. Livrable attendu : Pipeline de déploiement complet avec les étapes de bascule, les métriques de promotion automatique et le plan de rollback en moins de 2 minutes.