Concepto clave
El caching con Redis es una técnica que almacena temporalmente resultados de consultas costosas de base de datos en memoria RAM, permitiendo respuestas ultrarrápidas para peticiones repetidas. Imagina un restaurante muy concurrido: en lugar de que cada cliente espere a que el chef prepare su plato desde cero (consulta a base de datos), el restaurante mantiene algunos platos ya preparados en una mesa caliente (Redis). Cuando llega un cliente que pide uno de esos platos, se sirve inmediatamente sin esperar la cocción completa.
Este enfoque reduce drásticamente la latencia y la carga en tu base de datos principal. En producción, un sistema de cache bien diseñado puede mejorar el rendimiento de tu aplicación en órdenes de magnitud, especialmente para datos que se leen frecuentemente pero cambian poco, como perfiles de usuario, catálogos de productos o configuraciones del sistema.
Cómo funciona en la práctica
Implementar cache con Redis sigue un patrón llamado cache-aside o lazy loading. Cuando tu aplicación necesita datos, primero verifica si están en Redis. Si están (cache hit), los devuelve inmediatamente. Si no están (cache miss), consulta la base de datos, almacena el resultado en Redis con un tiempo de expiración (TTL), y luego lo devuelve al cliente.
Ejemplo paso a paso para una API que obtiene información de usuario:
- Recibes una petición GET /users/123
- Verificas si la clave
user:123existe en Redis - Si existe, devuelves los datos desde Redis (latencia: ~1ms)
- Si no existe, consultas la base de datos MySQL/PostgreSQL
- Almacenas el resultado en Redis con
SETEX user:123 3600 '{"id":123,"name":"Maria"}'(expira en 1 hora) - Devuelves los datos al cliente
En producción, un TTL de 1 hora para datos de usuario es razonable, pero ajusta según la volatilidad de tus datos. Para datos que cambian frecuentemente, usa TTL más cortos.
Caso de estudio
Considera una plataforma de e-commerce con 10,000 productos. Cada página de producto genera una consulta SQL compleja con joins entre tablas de productos, inventario, precios y reseñas. Sin cache, esta consulta toma 200ms en promedio. Con 1000 usuarios concurrentes, la base de datos colapsaría.
Solución implementada:
| Escenario | Latencia | Consultas DB/min |
|---|---|---|
| Sin cache | 200ms | 60,000 |
| Con Redis cache (80% hit rate) | 5ms (cache hit) / 200ms (miss) | 12,000 |
Implementación técnica:
def get_product(product_id):
cache_key = f"product:{product_id}"
cached_data = redis.get(cache_key)
if cached_data:
return json.loads(cached_data)
# Cache miss - consulta DB
product_data = db.query("SELECT * FROM products WHERE id = ?", product_id)
# Almacena en Redis con TTL de 30 minutos
redis.setex(cache_key, 1800, json.dumps(product_data))
return product_dataErrores comunes
- Cache sin expiración (TTL infinito): Los datos se vuelven obsoletos. Siempre configura TTL apropiado según la frecuencia de cambio de tus datos.
- Invalidación incorrecta: Cuando actualizas datos en la base de datos, debes invalidar o actualizar el cache correspondiente. Olvidar esto causa inconsistencias.
- Cache de datos demasiado grandes: Redis funciona mejor con valores menores a 1MB. Evita cachear resultados de consultas que devuelvan miles de registros.
- Falta de monitoreo: No medir la tasa de hits/misses te impide optimizar. Monitorea métricas como hit rate, latencia y uso de memoria.
- Single point of failure: Depender de un solo nodo Redis. En producción, usa Redis Cluster o réplicas para alta disponibilidad.
Checklist de dominio
- Puedo explicar la diferencia entre cache hit y cache miss
- Sé configurar TTL apropiado según el tipo de datos
- Implemento correctamente el patrón cache-aside en mi código
- Manejo adecuadamente la invalidación de cache cuando los datos cambian
- Uso claves de cache consistentes y descriptivas (ej:
user:{id}:profile) - Monitoreo la tasa de hits y ajusto la estrategia según los resultados
- Comprendo cuándo NO usar cache (datos que cambian en cada consulta)
Implementa un sistema de cache para consultas de productos
Objetivo
Crear un servicio que cachee consultas de productos usando Redis, reduciendo la carga en la base de datos principal.
Requisitos previos
- Redis instalado y corriendo (localhost:6379)
- Base de datos PostgreSQL/MySQL con una tabla
products - Lenguaje de programación a elección (Python, Node.js, Java, etc.)
Pasos a seguir
- Crea una función
get_product_by_id(product_id)que implemente el patrón cache-aside - Usa el formato de clave
product:{id}en Redis - Configura un TTL de 300 segundos (5 minutos) para las entradas de cache
- Implementa invalidación de cache: cuando se actualice un producto, elimina o actualiza su entrada en Redis
- Agrega logging que muestre cuando ocurre cache hit vs cache miss
- Prueba tu implementación con al menos 100 consultas repetidas y mide la mejora en latencia
Criterios de éxito
- Las consultas repetidas para el mismo producto deben ser ~10x más rápidas
- La base de datos debe recibir menos consultas cuando los datos están en cache
- Los datos actualizados deben reflejarse correctamente después de la invalidación
- Usa el comando SETEX de Redis para almacenar datos con expiración automática
- Considera usar un hash en lugar de JSON stringificado si necesitas acceder a campos individuales del producto
- Para la invalidación, el comando DEL elimina una clave específica de Redis
Evalua tu comprension
Completa el quiz interactivo de arriba para ganar XP.