Caching infrastructure engineer (ingénieur infrastructure de cache)

Le caching infrastructure engineer, ou ingénieur infrastructure de cache, conçoit et exploite un service de cache distribué pour les applications. Ce service conserve des copies de données issues d’une source de référence afin de réduire la latence, c’est-à-dire le temps de réponse, et de soutenir la charge. Le spécialiste prend en compte la fraîcheur de ces copies et le comportement des applications lorsque le cache répond mal ou devient indisponible.

Son travail couvre le service partagé, les bibliothèques clientes qui permettent aux applications de l’utiliser et les mécanismes d’invalidation. Invalider une donnée consiste à retirer ou rendre inutilisable sa copie devenue obsolète après un changement dans la source. L’ingénieur doit aussi traiter les accès simultanés : une lecture commencée avant une modification peut remettre une ancienne valeur dans le cache après son invalidation.

La responsabilité dépasse donc l’ajout de Redis dans une application. Elle porte sur la relation entre les données sources, les copies partagées et les clients applicatifs. L’organisation doit préciser qui décide des règles de fraîcheur, qui modifie les clients et qui intervient lors d’un incident. Pour cadrer le rattachement, identifiez le responsable technique du service et les équipes dont les applications en dépendent, plutôt que de déduire l’autorité du seul intitulé.

Ingénieur infrastructure de cache, développeur backend et administrateur de bases de données : qui fait quoi ?

• Ingénieur infrastructure de cache : confiez-lui la conception et l’exploitation de la couche de cache, ses interfaces et sa cohérence avec les sources.
• Développeur backend : précisez sa responsabilité sur le code applicatif qui lit et modifie les données, en coordination avec le spécialiste du cache.
• Administrateur de bases de données : distinguez sa responsabilité sur la base source des choix relatifs aux copies mises en cache.

Cette répartition sert à cadrer le poste, sans imposer trois équipes séparées. La fiche couvre le cache applicatif distribué. Elle exclut l’administration générale des bases, l’exploitation de toute la plateforme et le cache de compilation.

Un cache doit accélérer l’accès aux données sans rendre leur usage incorrect. Le recrutement doit donc éclairer plusieurs décisions liées : quelles données copier, combien de temps les conserver et comment réagir à une modification de la source. Une baisse du temps de réponse ne suffit pas à juger la qualité du service si les applications lisent des valeurs périmées.

La durée de vie, ou TTL pour « time to live », fixe le temps pendant lequel une copie peut rester dans le cache. Son choix dépend des changements dans la source et de la fraîcheur attendue par l’application. L’éviction répond à une autre question : quelles données retirer lorsque la mémoire disponible ne suffit plus ? Confondre expiration et éviction risque de conduire à une configuration qui répond au problème de capacité sans traiter celui de la fraîcheur.

La disponibilité doit être examinée avec celle de la base source. Lorsqu’un cache disparaît, les applications peuvent reporter leurs lectures sur cette base. Il faut tester ce comportement et limiter le retour vers la source pour éviter de la surcharger. Amazon décrit également le regroupement de demandes simultanées pour une même donnée absente, afin de réduire les rafales de lectures.

Exemple fictif : plusieurs applications partagent un cache de données produit. Après une modification dans la base, une lecture déjà en cours remet une ancienne valeur dans le cache. Le responsable technique doit comprendre comment le candidat détecterait et traiterait cet enchaînement, au-delà d’un simple réglage de durée de vie.

Un profil qui ne connaît que l’intégration applicative d’un cache peut laisser de côté les reconnexions des clients, les changements de format ou les tests de panne. À l’inverse, recruter un spécialiste sans lui donner accès aux équipes qui modifient les données limite sa capacité à traiter l’invalidation. Avant de choisir le candidat, précisez les décisions qu’il pourra prendre sur le service et celles qui nécessiteront un accord avec les équipes utilisatrices.

• Concevoir le service de cache distribué en fonction des lectures applicatives, de la latence et de la charge attendues.
• Définir les règles d’expiration et d’invalidation selon les changements de la source et la fraîcheur nécessaire aux applications.
• Développer ou adapter les bibliothèques clientes qui gèrent connexions, délais maximaux, reconnexions et erreurs.
• Traiter les accès concurrents pour éviter qu’une lecture ancienne réintroduise une valeur périmée après invalidation.
• Dimensionner la mémoire et choisir une politique d’éviction adaptée à la capacité du cache.
• Suivre les lectures servies ou non par le cache, la mémoire, le processeur et la charge de la base source.
• Tester l’indisponibilité du cache et limiter les lectures reportées vers la base source.
• Préparer les changements de format des données mises en cache pour préserver la compatibilité pendant les déploiements.
• Protéger les échanges réseau du cache par des mécanismes de chiffrement adaptés.

Recherchez des acquis en programmation, concurrence et communication entre machines. Le candidat doit comprendre ce qui se passe lorsque plusieurs opérations s’exécutent en même temps et lorsqu’une réponse réseau tarde ou échoue. Un parcours centré sur l’application peut apporter ces bases, à condition qu’il ait conduit à travailler sur le comportement du cache et de ses clients.

Le module « Programmation système et répartie » du Cnam couvre notamment les processus Linux, les threads, la synchronisation, les sockets et les appels de procédure à distance. Les threads sont des fils d’exécution au sein d’un processus. Les sockets permettent la communication réseau. Ces enseignements peuvent construire des acquis utiles, sans constituer un parcours obligatoire pour ce métier.

Redis University propose aussi des cours et exercices sur Redis, son exploitation, la disponibilité et l’observabilité, c’est-à-dire le suivi du comportement du service par ses mesures. Ces formations complètent la pratique. Une attestation de réussite ne prouve pas que le candidat a déjà pris en charge un service en production. L’ancienne certification Redis Developer a été retirée en juin 2024 : évitez d’en faire une exigence actuelle dans la fiche de poste.

Pour apprécier l’expérience, distinguez les responsabilités exercées. Avoir utilisé un cache dans une application, adapté une bibliothèque cliente ou exploité un service partagé n’expose pas aux mêmes décisions. Demandez quelle partie le candidat a conçue, quelles modifications il pouvait décider et comment il a participé au traitement des incidents. Un diplôme seul ne permet pas d’établir cette autonomie. Ajustez les attentes aux décisions réellement confiées sur le cache, sans fixer une durée universelle de parcours.

Pour évaluer ce profil, reliez les responsabilités du poste à des réalisations expliquées, un cas pratique et des échanges avec les interlocuteurs techniques concernés.

1. Définir les critères avant l’entretien

Construisez une grille autour de la cohérence des données, du comportement des clients, de la capacité du cache et de la gestion des pannes. Ajoutez la coordination avec les équipes applicatives.

Pour chaque critère, précisez la décision que le candidat devra prendre dans votre organisation. Distinguez ce qu’il doit maîtriser seul de ce qu’il pourra préparer avec un autre spécialiste.

Si votre entreprise manque d’expertise en cache distribué, faites examiner le raisonnement technique par un expert compétent sur ces systèmes. Gardez au responsable du recrutement l’appréciation des responsabilités et de la coopération attendues.

2. Examiner une réalisation passée

Demandez au candidat de décrire un service auquel il a contribué, de la source de données jusqu’aux applications clientes. Faites préciser sa contribution personnelle et les décisions prises par d’autres.

Invitez-le à expliquer une règle d’expiration ou d’invalidation, puis un incident qui a remis cette règle en question. Demandez quelles mesures ont permis d’identifier le problème.

Un signal favorable est une explication qui relie les choix aux contraintes des applications. Soyez attentif aux réponses qui citent uniquement un produit ou attribuent tout le travail au collectif.

3. Faire raisonner sur un cas proche du poste

Exemple fictif : une lecture de la base commence, puis la donnée change et sa copie est invalidée. La première lecture se termine ensuite et remet l’ancienne valeur dans le cache.

Demandez au candidat de représenter l’ordre des opérations et d’identifier le risque. Invitez-le à proposer une solution et à expliquer les conditions dans lesquelles elle fonctionne.

Ajoutez ensuite une perte du cache et demandez comment les clients réagissent. Faites préciser la limitation des lectures vers la base et les mesures utiles pour suivre la situation.

Adaptez le cas aux mécanismes réellement utilisés. Si les clients possèdent un cache local Redis, examinez séparément la perte de leur canal d’invalidation et la purge nécessaire des copies locales.

Valorisez les hypothèses explicites et les tests proposés. Une réponse qui promet une disponibilité totale sans discuter les dépendances mérite d’être approfondie.

4. Examiner exploitation et changements

Demandez comment le candidat distinguerait saturation mémoire, lectures non servies par le cache et hausse de charge sur la source. Faites expliquer les différences entre expiration et éviction.

Présentez un changement de format des données et demandez comment préserver la compatibilité pendant le déploiement. Examinez aussi les délais maximaux, les reconnexions et la gestion des erreurs des clients.

Si votre service utilise Sentinel, demandez comment les clients prennent en charge le basculement. Faites préciser les limites de la réplication asynchrone, qui ne garantit pas la conservation de toutes les écritures acquittées.

5. Évaluer la coopération et confirmer les responsabilités

Demandez au candidat d’expliquer à un responsable produit un compromis entre fraîcheur et temps de réponse. Observez s’il nomme les conséquences sur l’usage et les décisions à partager.

Si le poste inclut du management, examinez séparément son expérience d’encadrement. Pour un poste d’expertise, privilégiez la coordination des changements avec les développeurs et les responsables de la base.

Lors des prises de références autorisées par le candidat, recherchez des éléments qui corroborent les responsabilités décrites et sa manière de traiter les incidents. Comparez ces retours aux réalisations exposées, sans remplacer l’analyse technique par une appréciation générale.