Questions d'entretien Microservices
1. Qu'est-ce qu'une architecture microservices et quand l'utiliser ?
L'architecture microservices decompose une application en services independants, chacun responsable d'un domaine metier specifique. Chaque service est deployable, scalable et developpe independamment. Utilisez les microservices quand : l'equipe depasse 8-10 developpeurs, les parties de l'application ont des besoins de scalabilite differents, vous voulez deployer frequemment des parties independantes, ou les technologies doivent varier par domaine. Evitez-les pour les petites equipes ou les MVP — un monolithe bien structure est souvent preferable.
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 etre disponible). Communication asynchrone : messagerie via un broker (Kafka, RabbitMQ, SQS). Les services publient et consomment des evenements. Plus resilient (decouplage temporel) mais plus complexe (eventual consistency). En pratique, combinez les deux : synchrone pour les requetes necessitant une reponse immediate, asynchrone pour les notifications et les traitements en arriere-plan.
3. Expliquez le pattern API Gateway.
L'API Gateway est le point d'entree unique pour tous les clients. Il route les requetes vers les bons microservices, et peut fournir : authentification/autorisation centralisee, rate limiting, load balancing, aggregation de reponses 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 gerer la coherence des donnees entre microservices ?
Chaque microservice possede sa propre base de donnees (Database per Service). La coherence est eventuelle (eventual consistency), pas immediate. Patterns : Saga (sequence de transactions locales avec compensations en cas d'echec), Outbox Pattern (ecrire l'evenement dans une table outbox de la meme transaction, puis le publier), Event Sourcing (stocker les evenements plutot que l'etat). Evitez 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" apres un certain nombre d'echecs et retourne immediatement une erreur (ou une reponse de fallback) sans appeler le service defaillant. Apres un delai, il passe en etat "half-open" pour tester si le service est retabli. S'il repond, le circuit se "ferme" et les appels reprennent normalement. Implementation : Resilience4j (Java), Polly (.NET), ou au niveau de l'API Gateway.
6. Comment gerer 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 ecoute les evenements et reagit, pas de coordinateur central — simple mais difficile a suivre), Orchestration (un orchestrateur central coordonne les etapes — plus facile a comprendre mais point central). Chaque etape a une compensation (rollback local) en cas d'echec. Exemple : commande e-commerce = creer commande -> reserver stock -> debiter paiement, avec compensations inverses.
8. Comment observer et debugger les microservices ?
Les trois piliers de l'observabilite : Logs (journaux structures, centralises avec ELK/Loki), Metriques (mesures numeriques, Prometheus + Grafana), Traces (suivi d'une requete a travers les services, Jaeger/Zipkin/Tempo). Implementez un correlation ID propage dans tous les appels pour suivre une requete 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 strategie de migration progressive d'un monolithe vers des microservices. Au lieu de reecrire tout d'un coup (big bang), vous : identifiez un domaine a extraire, creez 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'a disparaitre.
10. Comment dimensionner et deployer les microservices ?
Chaque service doit etre conteneurise (Docker) et orchestre (Kubernetes). Deploiement : strategies canary ou blue-green par service. Dimensionnement : Horizontal Pod Autoscaler (HPA) base sur le CPU/memoire/metriques 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.