Questions d'entretien Microservices
1. Qu'est-ce qu'une architecture microservices et quand l'utiliser ?
L'architecture microservices decompose une application en services indépendants, chacun responsable d'un domaine métier spécifique. Chaque service est déployable, scalable et développe indépendamment. Utilisez les microservices quand : l'équipe dépasse 8-10 développeurs, les parties de l'application ont des besoins de scalabilité différents, vous voulez déployer fréquemment des parties indépendantes, ou les technologies doivent varier par domaine. Evitez-les pour les petites équipes ou les MVP — un monolithe bien structure est souvent préférable.
2. Comment les microservices communiquent-ils entre eux ?
Communication synchrone : appels HTTP/REST ou gRPC entre services. Simple mais cree un couplage temporel (le service appele doit être disponible). Communication asynchrone : messagerie via un broker (Kafka, RabbitMQ, SQS). Les services publient et consomment des événements. Plus resilient (decouplage temporel) mais plus complexe (eventual consistency). En pratique, combinez les deux : synchrone pour les requêtes nécessitant une réponse immédiate, asynchrone pour les notifications et les traitements en arriere-plan.
3. Expliquez le pattern API Gateway.
L'API Gateway est le point d'entrée unique pour tous les clients. Il route les requêtes vers les bons microservices, et peut fournir : authentification/autorisation centralisée, rate limiting, load balancing, aggregation de réponses de plusieurs services, transformation de protocoles, et caching. Outils populaires : Kong, AWS API Gateway, Nginx, Traefik. Attention au single point of failure : dimensionnez et redundez l'API Gateway correctement.
4. Comment gérer la cohérence des données entre microservices ?
Chaque microservice possède sa propre base de données (Database per Service). La cohérence est eventuelle (eventual consistency), pas immédiate. Patterns : Saga (séquence de transactions locales avec compensations en cas d'échec), Outbox Pattern (écrire l'événement dans une table outbox de la même transaction, puis le publier), Event Sourcing (stocker les événements plutôt que l'état). Évitez les transactions distribuees (2PC) qui couplent les services et degradent les performances.
5. Qu'est-ce que le pattern Circuit Breaker ?
Le Circuit Breaker previent les cascades de pannes. Quand un service distant echoue, le circuit breaker "s'ouvre" après un certain nombre d'échecs et retourne immédiatement une erreur (ou une réponse de fallback) sans appeler le service defaillant. Après un délai, il passe en état "half-open" pour tester si le service est retabli. S'il répond, le circuit se "ferme" et les appels reprennent normalement. Implémentation : Resilience4j (Java), Polly (.NET), ou au niveau de l'API Gateway.
6. Comment gérer le service discovery ?
Le Service Discovery permet aux services de se trouver dynamiquement. Deux approches : Client-side discovery (le client interroge un registre et choisit une instance, ex: Netflix Eureka), Server-side discovery (un load balancer interroge le registre, ex: AWS ALB + ECS). En Kubernetes, le discovery est natif via les Services (DNS interne). Outils : Consul (HashiCorp), Eureka (Netflix), etcd, ou simplement le DNS de Kubernetes.
7. Expliquez le pattern Saga et ses variantes.
Le pattern Saga gere les transactions distribuees sur plusieurs services. Deux approches : Choreographie (chaque service écoute les événements et reagit, pas de coordinateur central — simple mais difficile à suivre), Orchestration (un orchestrateur central coordonne les étapes — plus facile à comprendre mais point central). Chaque étape à une compensation (rollback local) en cas d'échec. Exemple : commande e-commerce = créer commande -> reserver stock -> debiter paiement, avec compensations inverses.
8. Comment observer et debugger les microservices ?
Les trois piliers de l'observabilité : Logs (journaux structures, centralises avec ELK/Loki), Métriques (mesures numériques, Prometheus + Grafana), Traces (suivi d'une requête à travers les services, Jaeger/Zipkin/Tempo). Implémentez un corrélation ID propage dans tous les appels pour suivre une requête de bout en bout. Les dashboards doivent afficher les RED metrics par service : Rate (debit), Errors (taux d'erreur), Duration (latence).
9. Qu'est-ce que le pattern Strangler Fig pour migrer vers les microservices ?
Le Strangler Fig (figuier etrangleur) est une stratégie de migration progressive d'un monolithe vers des microservices. Au lieu de reecrire tout d'un coup (big bang), vous : identifiez un domaine à extraire, créez un nouveau microservice pour ce domaine, routez progressivement le trafic du monolithe vers le nouveau service (via un proxy/API Gateway), et supprimez le code correspondant du monolithe. Le monolithe "retrecit" progressivement jusqu'à disparaitre.
10. Comment dimensionner et déployer les microservices ?
Chaque service doit être conteneurise (Docker) et orchestre (Kubernetes). Déploiement : stratégies canary ou blue-green par service. Dimensionnement : Horizontal Pod Autoscaler (HPA) base sur le CPU/mémoire/métriques custom. Bonnes pratiques : un service par pod, health checks (liveness + readiness probes), resource requests et limits, graceful shutdown. Utilisez des Helm charts ou Kustomize pour templatiser les deployments.