Développeur backend Questions d'entretien & Réponses

Exemple de réponse

Notre API renvoyait des erreurs 500 de façon intermittente, affectant environ 5 % des requêtes, mais uniquement aux heures de pointe. Les journaux d'erreurs montraient des délais d'expiration de connexion à la base de données, alors que le CPU et la mémoire de celle-ci étaient stables. J'ai ajouté une surveillance du pool de connexions et découvert que nous épuisions la limite du pool (20 connexions). La cause profonde : une nouvelle fonctionnalité ouvrait une transaction en base de données, effectuait un appel HTTP vers un service externe dans cette transaction, et ce service prenait parfois plus de 30 secondes à répondre, bloquant la connexion à la base. J'ai corrigé le problème en restructurant le code pour effectuer l'appel HTTP en dehors de la transaction et n'ouvrir une connexion que pour l'écriture réelle en base. J'ai également augmenté la taille du pool à 50 comme tampon et ajouté des alertes sur l'utilisation du pool de connexions. Le taux d'erreurs 500 est immédiatement tombé à zéro.

Exemple de réponse

J'ai conçu une API d'intégration partenaire que 15 entreprises externes utiliseraient pour synchroniser des données produit avec notre plateforme. Avant d'écrire la moindre ligne de code, j'ai réalisé des entretiens avec 5 consommateurs potentiels de l'API pour comprendre leurs schémas d'intégration. J'ai appris qu'ils avaient besoin d'opérations par lots (pas uniquement du CRUD enregistrement par enregistrement) et souhaitaient des webhooks pour des mises à jour en temps réel. J'ai conçu l'API avec des conventions de nommage cohérentes, de la pagination, du filtrage et des réponses d'erreur complètes avec des messages exploitables : pas juste '400 Bad Request', mais '400 : Le champ prix doit être un nombre positif. Reçu : -5,99.' J'ai généré la documentation OpenAPI depuis le code, créé un environnement sandbox avec des données de test, et rédigé un guide de démarrage rapide avec des exemples en Python, Node.js et curl. J'ai aussi versionné l'API dès le premier jour (v1 dans le chemin d'URL). Résultat : le temps d'intégration moyen était de 3 jours au lieu des 2 semaines habituelles dans le secteur, et les tickets de support étaient 70 % moins nombreux que pour notre version précédente de l'API.

Exemple de réponse

Nous devions migrer 500 millions de lignes d'une base MySQL monolithique vers PostgreSQL tout en maintenant l'application en fonctionnement : zéro temps d'arrêt était une exigence absolue. J'ai conçu une approche en phases. Phase 1 : configurer PostgreSQL avec le nouveau schéma et implémenter la double écriture, l'application écrivant simultanément dans les deux bases. Phase 2 : remplissage des données historiques via un script de migration par lots traitant 100 000 lignes par heure pendant les heures creuses, avec des sommes de contrôle pour vérifier l'intégrité des données. Phase 3 : basculer progressivement le trafic de lecture vers PostgreSQL via un feature flag, en commençant à 5 % et en augmentant sur 2 semaines tout en surveillant les écarts. Phase 4 : une fois 100 % des lectures sur PostgreSQL sans aucune alerte de discordance, arrêt des écritures MySQL et décommissionnement de l'ancienne base. La migration complète a pris 6 semaines. Nous avons détecté 3 bugs d'incohérence de données pendant la phase de double lecture, qui auraient causé des incidents en production lors d'une migration en une seule fois.

Exemple de réponse

J'ai réalisé un audit de sécurité de notre système d'authentification et identifié plusieurs problèmes : les tokens JWT avaient une expiration de 30 jours, les tokens de rafraîchissement étaient stockés dans localStorage (vulnérable aux attaques XSS), et la limitation de débit n'était appliquée qu'aux endpoints de connexion. J'ai mis en œuvre une refonte complète de la sécurité : réduction de l'expiration JWT à 15 minutes avec un rafraîchissement silencieux, déplacement des tokens de rafraîchissement vers des cookies HTTP-only sécurisés avec SameSite=Strict, implémentation d'une limitation par fenêtre glissante sur tous les endpoints authentifiés (100 requêtes par minute par utilisateur), ajout d'une signature de requête pour les opérations sensibles (virements, changements de mot de passe), et journalisation de tous les événements d'authentification. J'ai également mis en place une analyse automatique des vulnérabilités des dépendances avec Snyk dans notre pipeline CI. Après mise en œuvre, nous avons réussi un test de pénétration tiers sans aucune faille critique ou haute, contre 4 failles critiques lors de l'audit précédent.

Exemple de réponse

Le théorème CAP stipule qu'un système de stockage de données distribué peut garantir au plus deux des trois propriétés suivantes : la Cohérence (chaque lecture retourne la dernière écriture), la Disponibilité (chaque requête reçoit une réponse) et la Tolérance aux pannes réseau (le système continue de fonctionner malgré des défaillances réseau entre les nœuds). Les partitions réseau étant inévitables dans les systèmes distribués, le vrai choix se fait entre cohérence et disponibilité lors d'une partition. Les systèmes CP (comme PostgreSQL avec réplication synchrone, MongoDB, HBase) refusent de répondre plutôt que de retourner des données obsolètes : adaptés aux systèmes financiers où des données incorrectes sont pires qu'une interruption. Les systèmes AP (comme Cassandra, DynamoDB, CouchDB) répondent toujours mais peuvent retourner des données obsolètes : adaptés aux fils d'actualité de réseaux sociaux, aux catalogues produits ou aux couches de cache où la cohérence éventuelle est acceptable. En pratique, je choisis en fonction du coût d'une erreur : si des données obsolètes causent des pertes financières ou des problèmes de sécurité, je prends CP. Si un léger décalage de cohérence est invisible pour les utilisateurs, je prends AP pour une meilleure disponibilité et latence.

Exemple de réponse

J'évaluerais quatre algorithmes selon le cas d'utilisation. Fenêtre fixe : compter les requêtes dans des intervalles de temps fixes (par exemple, 100 par minute). Simple mais permet des pics aux limites des fenêtres : un utilisateur pourrait faire 100 requêtes à 0:59 et 100 autres à 1:00. Journal à fenêtre glissante : enregistrer l'horodatage de chaque requête, compter celles de la fenêtre précédente. Précis mais gourmand en mémoire pour les API à fort volume. Compteur à fenêtre glissante : hybride entre fixe et glissante, utilise le compteur de la fenêtre précédente pondéré par le chevauchement temporel. Bonne précision avec une faible consommation mémoire. Seau à jetons : les jetons s'accumulent à un rythme fixe, chaque requête coûte un jeton. Permet des pics contrôlés tout en maintenant le débit moyen. C'est mon choix par défaut : intuitif, il gère gracieusement le trafic en rafale et reste simple à implémenter. Pour l'implémentation : Redis avec INCR et EXPIRE pour la limitation distribuée, avec le format de clé user_id:endpoint:fenêtre. Je retournerais des en-têtes de limitation (X-RateLimit-Remaining, X-RateLimit-Reset) pour que les clients puissent s'autoréguler, et j'utiliserais des réponses HTTP 429 avec un en-tête Retry-After.

Exemple de réponse

Un index est une structure de données (généralement B-tree ou hash) qui accélère la récupération des données au détriment de la vitesse d'écriture et d'un stockage supplémentaire. C'est comme l'index d'un livre : au lieu de lire chaque page pour trouver un sujet, on le cherche dans l'index et on va directement à la bonne page. Utiliser des index sur : les colonnes dans les clauses WHERE (surtout sur les grandes tables), les colonnes de jointure, les colonnes utilisées dans ORDER BY, et les colonnes à forte cardinalité (beaucoup de valeurs uniques). Ne pas indexer : les petites tables (un balayage séquentiel est plus rapide), les colonnes à faible cardinalité (champs booléens, champs de statut avec 3 valeurs), les colonnes fréquemment mises à jour (surcharge de maintenance de l'index), ou les tables avec un trafic d'écriture intense où les performances de lecture ne sont pas critiques. Les index composites comptent : un index sur (user_id, created_at) aide les requêtes filtrant sur les deux, ou sur user_id seul, mais pas sur created_at seul. J'utilise EXPLAIN ANALYZE pour vérifier que les requêtes utilisent réellement les index que je crée : le planificateur ignore parfois les index lorsqu'il estime qu'un balayage séquentiel est plus rapide.

Exemple de réponse

Les transactions ACID traditionnelles ne fonctionnent pas entre microservices, car chaque service possède sa propre base de données. La solution standard est le pattern Saga : une séquence de transactions locales où chaque étape publie un événement déclenchant l'étape suivante, et chaque étape dispose d'une transaction compensatoire pour l'annulation. Il existe deux approches : la chorégraphie (les services réagissent de façon autonome aux événements) et l'orchestration (un coordinateur central gère le flux). Je préfère l'orchestration pour les flux complexes, car la logique est centralisée et plus facile à déboguer. Exemple : le traitement d'une commande implique le service Commandes (créer la commande), le service Paiement (débiter la carte) et le service Inventaire (réserver le stock). Si le paiement échoue, l'orchestrateur appelle la transaction compensatoire du service Commandes pour annuler la commande. Si l'inventaire échoue après le paiement, l'orchestrateur rembourse le paiement et annule la commande. Points clés : l'idempotence est critique (chaque étape doit gérer d'être appelée deux fois), les transactions compensatoires doivent être fiables, et une bonne observabilité sur l'état du saga est indispensable pour déboguer les flux en échec.

Exemple de réponse

Immédiat (15 premières minutes) : activer un cache agressif au niveau CDN/proxy inverse pour les endpoints à lecture intensive. Activer l'auto-scaling des serveurs d'application s'il n'est pas déjà en cours. Vérifier si la base de données est le goulot d'étranglement : si oui, activer des réplicas de lecture pour les requêtes GET et ajouter un pool de connexions (PgBouncer pour PostgreSQL). Court terme (heure suivante) : implémenter une limitation des requêtes pour les endpoints non critiques afin de protéger les chemins critiques. Ajouter une file d'attente pour les écritures pouvant être traitées de façon asynchrone (événements d'analyse utilisateur, notifications par email). Envisager un disjoncteur sur les appels aux services externes qui pourraient provoquer des défaillances en cascade. Si c'est un trafic attendu (moment viral, lancement produit) : scaler horizontalement, ajouter des couches de cache, optimiser les requêtes les plus sollicitées en base de données. Si c'est inattendu (potentiel DDoS) : analyser les schémas de trafic, activer la limitation par IP, envisager des règles WAF. Après le pic : mener une revue de planification de la capacité pour définir des déclencheurs de mise à l'échelle qui géreraient automatiquement ce cas la prochaine fois.

Exemple de réponse

Ne jamais exécuter ALTER TABLE directement sur une table d'un milliard de lignes en production : cela verrouillera la table pendant des heures. J'utiliserais un outil de migration de schéma en ligne comme pt-online-schema-change (MySQL) ou pg_repack (PostgreSQL), qui crée une copie fantôme de la table, applique la modification, synchronise les données via des triggers, et permute les tables avec un verrouillage minimal. Pour l'ajout d'une colonne : l'ajouter d'abord comme nullable (rapide, pas de réécriture de table), remplir les données par lots pendant les heures creuses (traiter 10 000 lignes par lot avec un délai de 100 ms entre les lots), puis ajouter la contrainte NOT NULL si nécessaire une fois le remplissage terminé. Pour modifier le type d'une colonne : créer une nouvelle colonne avec le type cible, effectuer une double écriture dans les deux colonnes pendant la migration, remplir la nouvelle colonne, basculer les lectures de l'application vers la nouvelle colonne, puis supprimer l'ancienne. Les principes clés : chaque étape doit être réversible, la migration doit s'exécuter en arrière-plan sans verrouillage, et l'application doit fonctionner correctement à chaque état intermédiaire.

Exemple de réponse

En premier lieu, implémenter un pattern disjoncteur (circuit breaker). Après N échecs consécutifs (disons 5), ouvrir le circuit : arrêter d'appeler l'API et retourner une réponse de secours (données en cache, valeurs par défaut, ou un message de dégradation gracieuse) pendant une période de refroidissement. Après le refroidissement, laisser passer une seule requête test. Si elle réussit, fermer le circuit et reprendre le fonctionnement normal. Ensuite, ajouter une logique de retry avec backoff exponentiel pour les échecs transitoires : réessayer après 1 s, puis 2 s, puis 4 s, avec du jitter pour éviter l'effet troupeau. Troisièmement, implémenter une file d'attente pour que les opérations dépendant de cette API puissent être relancées plus tard en cas d'échec. Quatrièmement, alerter l'équipe et consulter la page de statut du fournisseur tiers. Si le problème persiste, envisager de mettre davantage de réponses en cache, de construire un fallback vers un fournisseur alternatif, ou de mettre les requêtes en file pour un traitement par lots pendant les périodes stables. Long terme : pour toute dépendance critique envers un tiers, je maintiens un accord de niveau de service et dispose d'une stratégie de repli documentée avant le premier incident.

Exemple de réponse

Je le concevrais comme un système orienté événements avec trois couches. Première couche, la couche de requête de notification : les services publient des événements dans une file de messages (RabbitMQ ou SQS) avec une charge utile agnostique au canal : destinataire, type de notification, nom du template et variables de template. Cela découple l'émetteur de la mécanique de livraison. Deuxième couche, la couche d'orchestration : un service de notification consomme les événements, consulte les préférences utilisateur (quels canaux ils ont activés), résout les templates et publie des messages spécifiques à chaque canal dans des files dédiées (file email, file push, file SMS). Troisième couche, la couche de livraison : des workers spécifiques à chaque canal consomment depuis leur file et appellent le fournisseur approprié (SendGrid pour l'email, FCM/APNS pour le push, Twilio pour les SMS). Chaque worker gère les retries, la limitation de débit et la logique spécifique au fournisseur de façon indépendante. Décisions de conception clés : des clés d'idempotence pour éviter les envois en double, un journal de notifications pour l'audit et le débogage, le stockage des préférences utilisateur pour la désinscription et la sélection du canal, et le versioning des templates pour pouvoir les mettre à jour sans redéploiement. J'implémenterais également une file de lettres mortes pour les notifications définitivement en échec, avec des alertes.