Cache & Infrastructure

Comment Redis fonctionne-t-il vraiment ?

Redis est souvent utilisé comme cache, broker de queues ou stockage temporaire. Mais derrière une simple clé, que se passe-t-il réellement ?

Rails

Rails.cache.fetch("users_count") do
  User.count
end

Laravel

Cache::remember('users_count', 3600, function () {
    return User::count();
});

La vraie question

Le sujet n’est pas seulement de savoir comment appeler Redis.

Une ligne comme Cache::remember() ou Rails.cache.fetch() cache une vraie mécanique d’infrastructure. Pour l’utiliser correctement, il faut comprendre ce que Redis fait avec la donnée et ce qu’il ne garantit pas par défaut.

Où est stockée la donnée ?

Pourquoi Redis est rapide ?

Que se passe-t-il au redémarrage ?

Redis est-il une base de données ?

Quand faut-il éviter Redis ?

Image mentale

Redis comme un serveur très proche de votre application.

Application

↓

Client Redis

↓

TCP Socket

↓

Serveur Redis

↓

RAM

↓

Persistance optionnelle

Performance

Pourquoi Redis est rapide ?

Redis travaille principalement en mémoire RAM, ce qui évite beaucoup de lectures disque.

Ses structures de données sont simples, spécialisées et efficaces : clés, chaînes, listes, sets, hashes ou sorted sets.

Il évite souvent des lectures SQL répétées pour des données déjà calculées ou très consultées.

Il réduit le temps de réponse quand une application relit souvent les mêmes informations.

Persistance

Redis garde-t-il les données après redémarrage ?

Redis stocke d’abord les données en mémoire RAM. La persistance existe, mais elle est optionnelle et doit être configurée selon le risque accepté.

RDB

Redis écrit des snapshots périodiques sur disque. C’est compact, mais une coupure peut perdre les dernières écritures.

AOF

Redis journalise les commandes d’écriture. C’est souvent plus protecteur, avec un coût disque plus élevé.

Sans configuration adaptée, Redis ne doit pas être considéré comme la base principale pour des données critiques.

Cas d’usage

Où Redis apporte une vraie valeur.

Cache de requêtes SQL

Stocker le résultat d’un calcul ou d’une requête coûteuse pour éviter de la rejouer à chaque page.

Sessions utilisateurs

Partager les sessions entre plusieurs serveurs applicatifs avec un accès très rapide.

Rate limiting

Compter les requêtes par utilisateur, IP ou clé API sur une fenêtre de temps courte.

Queues / Jobs

Découpler une requête HTTP d’un traitement long via des workers en arrière-plan.

Compteurs

Incrémenter rapidement des métriques, vues, tentatives ou événements temporaires.

Données temporaires

Garder des valeurs avec expiration : tokens, verrous, résultats intermédiaires ou états transitoires.

Attention

Quand ne pas utiliser Redis ?

Données critiques sans stratégie claire de persistance, sauvegarde et restauration.

Données très rarement lues, pour lesquelles le cache n’apporte presque rien.

Complexité inutile sur une application qui n’a pas encore de problème de performance mesurable.

Cache sans invalidation claire, qui finit par servir des informations obsolètes.

Redis n’est pas magique.

C’est un outil très puissant quand il est utilisé pour le bon problème : réduire des lectures répétées, accélérer des traitements ou découpler certaines opérations.

Performance backend

Besoin d’optimiser une application web ?

J’accompagne les équipes sur Ruby on Rails, Laravel, Redis, queues, cache, performance backend et architecture applicative.

Prendre rendez-vous Voir les Labs