Redis — cache en mémoire pour des sites et boutiques
Redis est la couche de vitesse derrière les sites, boutiques et places de marché construits sur 4buildsite : il garde en mémoire vive (RAM) exactement les données à servir sans repasser par la base — pages en cache, sessions, paniers, limites de débit. La source de vérité reste PostgreSQL ; Redis la protège en cas de fort trafic et réduit les lectures répétées sur celle-ci. Il est compris et géré par la plateforme, sans aucune configuration de votre part.
Ce qu'est Redis et pourquoi il est si rapide
Redis (REmote DIctionary Server) est une base de données en mémoire open source : elle garde les données en RAM plutôt que sur disque. Sur 4buildsite, nous l'utilisons comme couche d'accélération devant PostgreSQL — pour tout ce qui doit être servi rapidement : pages, sessions, paniers et limites de débit.
Contrairement à un disque, la RAM est plus rapide de plusieurs ordres de grandeur, et Redis y ajoute des structures de données natives (chaîne, hachage, liste, ensemble, ensemble trié, flux) qui permettent des opérations complexes directement en mémoire, sans aller-retour vers la base principale. Le traitement des commandes se fait sur un seul fil d'exécution : le comportement est donc prévisible et exempt de situations de compétition.
- Données servies depuis la mémoire vive, sur un seul nœud
- Structures natives : hachages pour les sessions, ensembles triés pour les classements et la limitation de débit, flux pour les files
- Un seul fil d'exécution pour les commandes → comportement prévisible, sans blocages complexes
Cache : vos pages et vos données, servies depuis la mémoire
La stratégie est le cache-aside : la première requête lit dans PostgreSQL et enregistre le résultat dans Redis avec une TTL (durée de vie) ; les requêtes suivantes le prennent directement en mémoire. Lorsque vous modifiez une page, la clé est supprimée explicitement — nous ne servons jamais de données périmées par le biais d'une TTL aveugle.
Pour un site vitrine ou une boutique, cela signifie que les listes de produits, les menus, les pages populaires et les fragments de contenu sont livrés depuis la mémoire, sans surcharger la base de données. Lors des pics (une campagne, le Black Friday), Redis absorbe les requêtes répétées et protège la base de données.
- Cache-aside avec invalidation explicite — aucune donnée périmée
- Mémorise des fragments de page et des résultats de requêtes, pas seulement des pages entières
- Protège PostgreSQL lors des pics de trafic et réduit les temps de réponse
Sessions, panier d'achat et protection contre les abus
Les sessions utilisateur et les jetons de rafraîchissement résident dans Redis : authentification, expiration automatique par TTL et révocation sur tous les appareils lorsqu'une personne se déconnecte ou change de mot de passe.
Le panier d'achat des boutiques construites sur 4buildsite est conservé dans Redis pour les visiteurs non connectés — avec expiration, et sans gonfler la base principale. C'est également Redis qui applique la limitation de débit sur les formulaires de contact et à la connexion, à l'aide d'ensembles triés, afin de bloquer le spam et les tentatives par force brute avant qu'ils n'atteignent la base de données.
- Magasin de sessions avec expiration automatique et révocation sélective des jetons
- Panier persistant avec TTL pour les visiteurs anonymes
- Limitation de débit et protection contre les abus sur les formulaires et l'authentification
Temps réel et files de traitements en arrière-plan
Le Pub/Sub et les Streams de Redis alimentent les mises à jour en temps réel : un stock qui diminue en direct, une notification dans l'application, le statut d'une commande qui change — le tout sans que le visiteur ait à rafraîchir et sans interrogation répétée qui épuise le serveur.
Les tâches lourdes (traiter une image, générer un export, effectuer une synchronisation) entrent dans une file Redis et sont exécutées par des workers en arrière-plan, afin que la requête du visiteur n'attende pas leur exécution. Un mécanisme de verrouillage distribué garantit qu'une opération critique ne s'exécute pas deux fois.
- Pub/Sub et Streams pour les événements en direct (stock, commandes, notifications)
- Files de traitements pour les tâches lourdes exécutées de façon asynchrone
- Verrouillage distribué pour les opérations qui ne doivent pas s'exécuter deux fois
Avantages et limites
Avantages
- Données en cache servies depuis la mémoire vive, sans passer par la base
- Réduit fortement la charge sur PostgreSQL en cas de fort trafic
- Structures natives pour les sessions, le panier, la limitation de débit et les classements
- Pub/Sub et Streams pour les fonctions en temps réel, sans interrogation répétée
- Files de traitements pour les tâches lourdes, exécutées en arrière-plan
- Compris et géré par la plateforme — aucune configuration de votre côté
Limites
- Les données résident en RAM, plus chère que le disque → inadapté à d'énormes volumes de données « froides »
- C'est un cache, une couche auxiliaire, et non la source de vérité — les données permanentes restent dans PostgreSQL
- La persistance (RDB/AOF) réduit, sans l'éliminer totalement, le risque de perdre les dernières secondes lors d'un incident
- Exige une stratégie d'invalidation correcte, faute de quoi il peut servir des données périmées
Verdict en bref
Utilisez Redis pour tout ce qui doit être servi rapidement — cache, sessions, panier, limitation de débit, temps réel et files de traitements. Ne l'employez pas comme entrepôt principal de données ; PostgreSQL reste là pour cela. Sur 4buildsite, vous disposez des deux, associés automatiquement : vous n'avez ni à choisir ni à configurer quoi que ce soit.
Tableau des spécifications
| Capacité | Détail | Usage dans le builder |
|---|---|---|
| Latence | En mémoire vive (RAM) | Pages et données servies depuis la mémoire |
| Débit | Débit élevé par nœud | Lectures répétées absorbées par le cache, hors de la base |
| Structures de données | chaîne, hachage, liste, ensemble, ensemble trié, flux | Sessions, panier, classements, files, limitation de débit |
| Persistance | Instantané RDB et journal AOF | Reprise rapide après un redémarrage |
| Expiration | TTL par clé | Panier, sessions et cache à nettoyage automatique |
| Temps réel | Pub/Sub et Streams | Stock en direct, notifications, statut de commande |
Redis (cache) face à la base de données seule
| Critère | Avec Redis | PostgreSQL seul |
|---|---|---|
| Temps de réponse sur des données répétées | depuis la mémoire vive | une requête à la base à chaque appel |
| En cas de fort trafic | base protégée, montée en charge aisée | la base s'engorge et risque des dépassements de délai |
| Panier et sessions | rapides, avec expiration automatique | des tables qui grossissent et chargent la base |
| Temps réel | Pub/Sub et Streams natifs | interrogation répétée, coûteuse |
| Files de traitements | natives, simples à utiliser | solutions bricolées ou inexistantes |
Questions fréquentes
Qu'est-ce que Redis, en bref ?
Une base de données en mémoire vive, utilisée comme couche de cache, de sessions et de temps réel devant la base principale. Elle sert les données depuis la RAM, sans passer par le disque.
Pourquoi ne pas se contenter de PostgreSQL ?
PostgreSQL est la source de vérité (les données durables), mais Redis sert les données répétées depuis la mémoire vive et prend en charge le panier, les sessions, la limitation de débit et le temps réel, ce qui protège la base en cas de fort trafic. Les deux travaillent ensemble.
Est-ce que je perds des données si Redis tombe ?
Pas le contenu du site : les données permanentes sont dans PostgreSQL. Redis ne contient que du cache et des données temporaires, et la persistance RDB/AOF limite les pertes.
Dois-je configurer Redis moi-même ?
Non. Il est compris et géré par la plateforme 4buildsite ; vous profitez des fonctions temps réel sans rien administrer.
En quoi Redis aide-t-il une boutique en ligne ?
Un panier pour les visiteurs, des listes de produits en cache, un stock mis à jour en direct et une protection contre les abus au moment du paiement et sur les formulaires — le tout sans charger la base de données.
Redis aide-t-il au SEO et aux Core Web Vitals ?
Oui, indirectement : des temps de réponse courts améliorent le TTFB et les Core Web Vitals, des signaux qui comptent pour Google et pour l'expérience utilisateur.