Redis — caché en memoria para webs y tiendas
Redis es la capa de velocidad detrás de las webs, tiendas y marketplaces construidos en 4buildsite: mantiene en memoria (RAM) exactamente los datos que deben servirse al instante —páginas cacheadas, sesiones, carritos, límites de peticiones— y responde en menos de un milisegundo. La fuente de verdad sigue siendo PostgreSQL; Redis la protege cuando hay mucho tráfico. Va incluido y lo gestiona la plataforma, sin ninguna configuración por tu parte.
Qué es Redis y por qué es tan rápido
Redis (REmote DIctionary Server) es una base de datos en memoria de código abierto: guarda los datos en la RAM y no en el disco, así que responde en menos de un milisegundo. En 4buildsite lo usamos como capa de aceleración delante de PostgreSQL, para todo lo que debe servirse al instante: páginas, sesiones, carritos y límites de peticiones.
A diferencia de un disco, la RAM es órdenes de magnitud más rápida, y Redis añade estructuras de datos nativas (cadena, hash, lista, conjunto, conjunto ordenado, stream) que permiten operaciones complejas directamente en memoria, sin ida y vuelta a la base principal. El procesamiento de comandos es de un solo hilo, de modo que el comportamiento es predecible y no hay condiciones de carrera.
- Latencia habitual por debajo de 1 ms y más de 100.000 operaciones por segundo en un solo nodo
- Estructuras nativas: hashes para las sesiones, conjuntos ordenados para rankings y limitación de peticiones, streams para las colas
- Un solo hilo para los comandos → comportamiento predecible, sin bloqueos complejos
Caché: tus páginas y datos, servidos desde memoria
La estrategia es cache-aside: la primera petición lee de PostgreSQL y guarda el resultado en Redis con un TTL (tiempo de vida); las siguientes lo toman directamente de la memoria. Cuando editas una página, la clave se borra de forma explícita: nunca servimos datos obsoletos por culpa de un TTL a ciegas.
Para una web corporativa o una tienda, eso significa que las listas de productos, los menús, las páginas populares y los fragmentos de contenido se entregan incluso con mucho tráfico, sin saturar la base de datos. En los picos (una campaña, el Black Friday) Redis absorbe las peticiones repetidas.
- Cache-aside con invalidación explícita: sin datos obsoletos
- Guarda fragmentos de página y resultados de consultas, no solo páginas enteras
- Protege PostgreSQL en los picos de tráfico y reduce los tiempos de respuesta
Sesiones, carrito de la compra y protección contra abusos
Las sesiones de usuario y los tokens de refresco viven en Redis: autenticación rápida, caducidad automática mediante TTL y revocación inmediata en todos los dispositivos cuando alguien cierra sesión o cambia la contraseña.
El carrito de la compra de las tiendas construidas en 4buildsite se guarda en Redis para los visitantes no autenticados: con caducidad y sin hinchar la base principal. También es Redis quien aplica la limitación de peticiones en los formularios de contacto y en el inicio de sesión, usando conjuntos ordenados, para frenar el spam y los intentos de fuerza bruta antes de que lleguen a la base de datos.
- Almacén de sesiones con caducidad automática y revocación selectiva de los tokens
- Carrito persistente con TTL para visitantes anónimos
- Limitación de peticiones y protección antiabuso en formularios y autenticación
Tiempo real y colas de trabajos en segundo plano
El Pub/Sub y los Streams de Redis alimentan las actualizaciones en tiempo real: un inventario que baja en directo, una notificación en la aplicación, el estado de un pedido que cambia; todo sin que el visitante tenga que recargar y sin un sondeo repetido que agote el servidor.
Las tareas pesadas (procesar una imagen, generar una exportación, una sincronización) entran en una cola de Redis y las ejecutan procesos en segundo plano, para que el visitante reciba respuesta. Un mecanismo de bloqueo distribuido garantiza que una operación crítica no se ejecute dos veces.
- Pub/Sub y Streams para eventos en directo (inventario, pedidos, notificaciones)
- Colas de trabajos para procesos pesados ejecutados de forma asíncrona
- Bloqueo distribuido para operaciones que no deben ejecutarse dos veces
Ventajas y limitaciones
Ventajas
- Respuesta en menos de 1 ms: los datos cacheados se sirven desde memoria
- Reduce drásticamente la carga sobre PostgreSQL cuando hay mucho tráfico
- Estructuras nativas para sesiones, carrito, limitación de peticiones y rankings
- Pub/Sub y Streams para funciones en tiempo real, sin sondeo
- Colas de trabajos para procesos pesados, sin hacer esperar al visitante
- Incluido y gestionado por la plataforma: cero configuración por tu parte
Limitaciones
- Los datos residen en RAM, más cara que el disco → no sirve para volúmenes enormes de datos «en frío»
- Es una caché o capa auxiliar, no la fuente de verdad: los datos permanentes se quedan en PostgreSQL
- La persistencia (RDB/AOF) reduce, pero no elimina del todo, el riesgo de perder los últimos segundos ante una caída
- Requiere una estrategia de invalidación correcta; de lo contrario puede servir datos obsoletos
Veredicto breve
Usa Redis para todo lo que deba ser instantáneo: caché, sesiones, carrito, limitación de peticiones, tiempo real y colas de trabajos. No lo uses como almacén principal de datos; para eso está PostgreSQL. En 4buildsite tienes ambos, combinados automáticamente: no tienes que elegir ni configurar nada.
Tabla de especificaciones
| Capacidad | Detalle | Dónde se usa en el builder |
|---|---|---|
| Latencia | < 1 ms (en memoria) | Páginas y datos servidos desde memoria |
| Rendimiento | > 100.000 operaciones/s por nodo | Mucho tráfico sin que caiga la base de datos |
| Estructuras de datos | cadena, hash, lista, conjunto, conjunto ordenado, stream | Sesiones, carrito, rankings, colas, limitación de peticiones |
| Persistencia | Instantánea RDB y registro AOF | Recuperación rápida tras un reinicio |
| Caducidad | TTL por clave | Carrito, sesiones y caché con autolimpieza |
| Tiempo real | Pub/Sub y Streams | Inventario en directo, notificaciones, estado del pedido |
Redis (caché) frente a usar solo la base de datos
| Criterio | Con Redis | Solo PostgreSQL |
|---|---|---|
| Tiempo de respuesta con datos repetidos | menos de 1 ms, desde la memoria | decenas de ms, una consulta en cada petición |
| Con mucho tráfico | base protegida, escala con facilidad | la base se congestiona y arriesga tiempos de espera agotados |
| Carrito y sesiones | rápidos, con caducidad automática | tablas que crecen y cargan la base |
| Tiempo real | Pub/Sub y Streams nativos | sondeo repetido, costoso |
| Colas de trabajos | nativas y sencillas de usar | soluciones improvisadas o inexistentes |
Preguntas frecuentes
¿Qué es Redis, en pocas palabras?
Una base de datos en memoria ultrarrápida, usada como capa de caché, sesiones y tiempo real por delante de la base principal. Responde en menos de un milisegundo.
¿Por qué no usar solo PostgreSQL?
PostgreSQL es la fuente de verdad (datos duraderos), pero Redis sirve los datos repetidos en menos de un milisegundo y asume el carrito, las sesiones, la limitación de peticiones y el tiempo real, protegiendo la base cuando hay mucho tráfico. Los dos trabajan juntos.
¿Pierdo datos si Redis se cae?
El contenido de la web no: los datos permanentes están en PostgreSQL. En Redis solo hay caché y datos temporales, y la persistencia RDB/AOF reduce las pérdidas. Un reinicio de Redis no afecta a tu web publicada.
¿Tengo que configurar yo Redis?
No. Va incluido y lo gestiona la plataforma 4buildsite; tú te beneficias de la velocidad y de las funciones en tiempo real sin administrar nada.
¿En qué ayuda Redis a una tienda online?
Carrito para los visitantes, listas de productos cacheadas, inventario actualizado en directo y protección antiabuso en el proceso de pago y en los formularios, todo sin cargar la base de datos.
¿Redis influye en el TTFB de la web?
Sí, de forma indirecta: el TTFB (tiempo hasta el primer byte) mide cuánto tarda el servidor en empezar a responder, y servir los datos repetidos desde la memoria acorta ese tiempo frente a una consulta a la base de datos en cada petición.