Redis : cas d'usage

Prérequis : cours 6.2 (cache) du cursus Architecture — ou culture cache de base.

Pourquoi

Tout n'a pas besoin d'ACID : sessions, files, compteurs, classements temps réel — Redis (en mémoire, structures riches) fait ça 100× plus vite que Postgres, pour ce qu'il fait bien.

Concepts

• En mémoire d'abord : microsecondes vs millisecondes. Prix : RAM chère + persistance à configurer (sinon restart = amnésie).
• Structures : Strings (cache, compteurs INCR), Hashes (objets/sessions), Lists (files simples), Sets/Sorted Sets (tags, classements, ZADD/ZRANGE), Streams (journal persistant, base du messaging léger), Pub/Sub (éphémère ! message perdu si personne n'écoute).
• Bonnes cibles : cache, sessions à TTL, rate limiting (INCR + EXPIRE), files simples, leaderboards. Mauvaises : données critiques uniques, requêtes complexes, ce qui doit survivre sans config.

Exemple : rate limiting en 3 lignes

INCR ratelimit:{ip}  →  EXPIRE ratelimit:{ip} 60 (si == 1)
-- > 100 ? 429 Too Many Requests

Atomique, distribué, 1 ms. En Postgres : verrous + lenteur.

Cas réel

Sessions en base « pour simplifier » : chaque requête = 1 SELECT session + jointures, base saturée à 2k rps. Sessions en Redis à TTL : base soulagée ×10, latence /3.

Pièges

• Redis comme seule copie de données critiques : panne = perte. Redis accélère, Postgres conserve.
• Clés sans TTL ni namespace (session:123 global) : fuite mémoire + collisions inter-apps (app:session:123, TTL toujours).
• Pub/Sub pour du critique : éphémère = perdu si down. Streams (persistants) pour ce qui compte.

À retenir

Mémoire + structures = vitesse ; TTL + namespace toujours ; critique = Postgres, chaud = Redis.