Questions d'entretien microservices

Vous avez lu les noms des patterns, vous pouvez réciter ce que fait un circuit breaker, et vous ne savez toujours pas ce qu'un jury écoute vraiment. Cette section nomme les quatre domaines évalués par les recruteurs, dans l'ordre où ils les sondent habituellement. Chacun est une question de jugement déguisée en question de vocabulaire.

• Décomposition. Où coupez-vous, et pourquoi là ? Les recruteurs veulent une limite tracée selon la capacité métier ou la propriété des données, pas selon les couches techniques.
• Communication. Requête/réponse synchrone ou événements asynchrones, et ce qui casse dans chaque cas. La réponse attendue est un compromis, pas une préférence.
• Données. Une base de données par service signifie aucune jointure inter-services et aucune transaction distribuée. Comment garder le système cohérent malgré tout ?
• Opérations. Déploiement, versionnement, traçage, et ce qui se passe à trois heures du matin quand un service est lent plutôt qu'en panne.

Notez qu'aucun de ces points ne concerne un framework. Un candidat qui explique pourquoi il a séparé le paiement de l'inventaire surpasse toujours celui qui liste des annotations.

Voici les questions qui ouvrent la plupart des entretiens microservices, avec ce que l'intervieweur vérifie derrière chacune.

• Comment découperiez-vous ce monolithe en services ? Vérifie si vous coupez selon les capacités métier et la propriété des données, ou selon les couches controller, service et repository. La seconde réponse produit un monolithe distribué.
• Comment deux services communiquent-ils entre eux ? Vérifie si vous savez nommer le coût de chaque choix : les appels synchrones donnent un modèle mental simple et couplent la disponibilité, les événements asynchrones découplent la disponibilité et imposent une cohérence à terme à expliquer à un product owner.
• Qu'est-ce qu'un monolithe distribué et comment l'éviter ? Vérifie si vous savez que des services qui doivent être déployés ensemble ne sont pas vraiment séparés.
• Quelle taille doit avoir un service ? Vérifie que vous résistez à donner un chiffre. La taille suit la limite et l'équipe qui la possède.
• Avez-vous besoin d'une API gateway, et à quoi sert-elle ? Vérifie si vous savez séparer routage, authentification et limitation de débit de la logique métier.
• Comment les services se trouvent-ils entre eux ? Vérifie une familiarité de base avec la découverte de services et pourquoi des hôtes codés en dur échouent à grande échelle.

Formulez le compromis à voix haute dans chaque réponse. Un jury ne peut pas noter une comparaison que vous avez faite silencieusement dans votre tête.

C'est ici que les entretiens se gagnent ou se perdent, car ces questions n'ont pas de réponse toute faite et les candidats se rabattent sur une réponse apprise par cœur.

• Comment gardez-vous les données cohérentes entre services ? Nommez d'abord la contrainte : il n'existe pas de transaction inter-services. Décrivez ensuite une saga, chorégraphiée par événements ou orchestrée par un coordinateur, et dites clairement que le système est cohérent à terme, ainsi que ce que voit l'utilisateur pendant l'écart.
• Que se passe-t-il quand un service en aval est lent ? Délais d'expiration, nouvelles tentatives avec backoff, et un circuit breaker pour qu'une dépendance lente n'épuise pas votre pool de threads. Lent est pire qu'en panne, et le dire montre une expérience de production.
• Comment rendre une nouvelle tentative sûre ? L'idempotence. Une clé d'idempotence sur le chemin d'écriture, pour qu'un paiement rejoué ne facture qu'une fois.
• Comment gérer une panne partielle dans un flux à plusieurs étapes ? Des actions compensatoires, pas un rollback. Expliquez à quoi ressemble un remboursement ou la libération d'une réservation.
• Comment déboguer une requête qui a touché six services ? Traçage distribué avec un identifiant de corrélation propagé à chaque saut, plus des logs structurés et des métriques.

Un ingénieur backend passant un entretien pour un poste plateforme L5 chez un fournisseur cloud public a reçu la question sur la saga et y a répondu du premier coup, dans le vocabulaire des patterns, sans jamais mentionner ce que verrait le client. La relance, ce qu'affiche la page de commande pendant la fenêtre incohérente, est la question qui décide vraiment de la manche. Préparez la seconde réponse, pas seulement la première.

D'autres banques de questions par rôle et par sujet sont regroupées sous questions d'entretien par rôle.

Lire cette liste produit une reconnaissance, et cette reconnaissance disparait quand un inconnu pose la question et attend. L'écart entre connaître un pattern et l'expliquer sous une légère pression est toute la difficulté d'une épreuve de system design, et il ne se comble qu'en parlant.

Choisissez un flux que vous connaissez bien, une commande ou une inscription, et racontez à voix haute la décomposition complète : la limite, le choix de communication, l'histoire de la cohérence, l'histoire de la panne. Faites-le jusqu'à ne plus recommencer vos phrases. Vous pouvez tester ces sollicitations face à un intervieweur IA qui pose des relances et vous laisse répondre à voix haute en mode simulation d'entretien, ce qui se rapproche plus de la réalité que de relire des notes.

Aaron Cao, fondateur de SubcueAI, a conçu ce mode d'entraînement autour de cet écart plutôt qu'autour de la diffusion de contenu. Les listes de questions sont disponibles gratuitement partout ; ce qui manque aux candidats, ce sont les répétitions de dire la réponse pendant que quelqu'un attend. Pendant un entretien réel, l'application de bureau et le panneau latéral de l'extension navigateur peuvent afficher des invites structurées pendant que l'intervieweur parle, même si une explication répétée bat toujours celle qu'on découvre en la lisant. Ce que l'assistant fait et ne fait pas est décrit sur la page présentation du produit.