Chapitre 4.3.3
Le cache applicatif

En informatique, une application désigne tout programme qui exécute une logique métier, qu’il s’agisse d’un site web, d’un service backend ou d’un logiciel installé. Les applications mobiles qu’on télécharge depuis les stores ne sont qu’un cas particulier. Le mot application ne renvoie donc pas à un appareil ou un format précis, mais à tout système qui exécute un traitement, qu’il soit local, web, distribué ou hébergé dans le cloud.

Le cache applicatif regroupe les systèmes utilisés directement par l’application pour accélérer son fonctionnement. Les développeurs y stockent principalement :

• Les résultats de requêtes en base de données.
• Les réponses des appels réseau vers d'autres briques internes ou des partenaires.

Prenons un exemple :

1. Tu veux afficher sur une page tes offres d'abonnement.
2. Ton catalogue d'offres est hébergé chez un partenaire. Il peut mettre jusqu'à 5 secondes pour te répondre, c'est-à-dire une éternité dans la navigation d'un client.
3. Tu veux proposer des offres différentes à un client européen et à un client américain.

Les offres ne changent pas tous les jours, on décide donc de les mettre en cache pour éviter l'appel de 5 secondes.

Deux stratégies possibles :

1. Le premier client qui arrive déclenche la requête vers le partenaire. Le résultat est mis en cache après 5 secondes d'attente. C’est la solution la plus simple et la plus courante.
2. Pour améliorer l'expérience du premier client, on peut développer un script pour préremplir le cache. On appelle ça du préchauffage (warmup).

Le préchauffage sert aussi, et notamment, à protéger les systèmes au moment du renouvellement du cache.

L'infrastructure de production est dimensionnée en prenant en compte le cache. Supprimer les anciennes données sans avoir préchauffé les nouvelles revient à retirer une couche de protection. Tous les clients qui chargent une page pendant les 5 secondes suivantes vont déclencher une requête vers le partenaire. Ça risque de provoquer un pic de trafic pour lui et une accumulation de connexions sur nos propres serveurs. Tout le système pourrait s'effondrer !

Pour l'exemple, nous allons laisser le premier client subir ces 5 secondes d'attente.

Premier client :

1. Il charge la page avec toutes les offres.
2. On détecte ce client comme étant européen. On regarde si les offres européennes sont déjà dans le cache : non.
3. On demande au partenaire de nous fournir les offres européennes. Il répond au bout de 5 secondes.
4. La réponse est stockée dans le cache.
5. La réponse est retournée au client pour qu'il puisse voir les offres sur la page.

Second client :

1. Il charge la page avec toutes les offres.
2. On détecte ce client comme étant européen. On regarde si les offres européennes sont déjà dans le cache : oui !
3. La réponse est retournée au client pour qu'il puisse voir les offres sur la page.

On a gagné 5 secondes par client ! Enfin, pour les européens… Le premier client américain va lui aussi devoir attendre 5 secondes.

Dans notre exemple, le cache est segmenté par un seul critère : le continent. C'est une liste finie dont on connaît les valeurs, on aurait pu facilement préchauffer le cache.

C'est loin d'être toujours le cas ! On pourrait segmenter les offres selon de multiples critères : ce client est déjà abonné et on ne veut lui proposer que de l'upgrade, ce client a résilié son abonnement et il faut essayer de le retenir, ce client a déjà bénéficié d'une promotion donc il ne faut pas lui en proposer une nouvelle…

Et si un cache est difficile à préchauffer, il sera aussi difficile à vider.