Redis: estrategias de caché que todo backend debería conocer

Actualizado: 2026-05-03

Redis^[1] es el caché in-memory dominante en backends modernos. Pero “poner Redis delante” no es una estrategia — es un ingrediente. Los equipos que usan Redis eficientemente han internalizado patrones específicos de interacción con la base de datos, diseño de TTL e invalidación. Este artículo repasa los más importantes.

Puntos clave

• Los cuatro patrones principales son cache-aside, read-through, write-through y write-behind: cada uno tiene trade-offs de consistencia, latencia y complejidad distintos.
• El diseño del TTL es la decisión más subestimada y uno de los mayores impactos en la tasa de hit.
• El thundering herd es el problema operativo más común con cachés bajo carga: jitter, request coalescing y early refresh lo mitigan.
• La invalidación explícita es imprescindible para datos donde la desactualización tiene consecuencias reales (precios, inventarios).
• Una tasa de hit inferior al 50% es señal de que el caché añade complejidad sin beneficio neto.

Los cuatro patrones principales

Cache-aside (lazy loading)

El patrón más común. La aplicación consulta primero al caché; si falla, consulta la base de datos y guarda el resultado.

def get_user(user_id):
    cached = redis.get(f"user:{user_id}")
    if cached:
        return json.loads(cached)
    user = db.query("SELECT * FROM users WHERE id = %s", user_id)
    redis.setex(f"user:{user_id}", 3600, json.dumps(user))  # TTL 1h
    return user

Pros: simple, resiliente si Redis cae (la app sigue funcionando con penalización de latencia). Contras: primer acceso siempre miss; riesgo de datos obsoletos entre escrituras.

Read-through

La aplicación consulta siempre al caché, y el caché se ocupa de rellenarse desde la base de datos cuando falta. Requiere biblioteca o proxy que medie.

Pros: lógica más simple en la aplicación. Contras: acoplamiento entre caché y base de datos, menos flexible ante cambios de esquema.

Write-through

Al escribir, la aplicación actualiza simultáneamente caché y base de datos. El caché siempre refleja el estado actual.

Pros: caché nunca está desactualizado. Contras: latencia de escritura aumenta al tocar dos sistemas; si el caché cae sin write-back se puede perder el dato.

Write-behind (write-back)

La aplicación escribe solo al caché; un proceso asíncrono persiste a la base de datos después.

Pros: latencia de escritura mínima. Contras: riesgo de pérdida de datos si el caché cae antes del flush. Solo apropiado donde la durabilidad no es crítica (contadores de analytics, logs intermedios).

Diseño de TTL

Decisión habitualmente subestimada. TTL demasiado corto genera muchos misses innecesarios; TTL demasiado largo produce datos obsoletos. Cuatro reglas prácticas:

• Datos que cambian predeciblemente: TTL = intervalo entre cambios. Tipo de cambio actualizado cada 5 min → TTL 5-10 min.
• Datos muy estables: TTL largo (horas o días). Perfil de usuario que cambia una vez al mes.
• Datos críticos para precisión: TTL corto + invalidación explícita en los escritores.
• Precios, inventarios, datos con consecuencias si se desactualizan: invalidación explícita, no solo TTL.

Thundering herd

Un problema clásico bajo carga: muchas peticiones concurrentes llegan al mismo cache miss simultáneamente. Todas llaman a la base de datos a la vez, saturándola.

Tres soluciones que se pueden combinar:

• Lock en caché (request coalescing). El primer miss toma un lock; las peticiones siguientes esperan y leen del caché una vez rellenado.
• TTL con jitter. En lugar de TTL fijo, TTL = base + aleatorio entre 0 y N%. Evita que miles de claves expiren simultáneamente.
• Early refresh. Antes de que el TTL expire, si la clave está próxima a caducar, una sola petición refresca en background mientras el resto sirve del valor aún válido.

Invalidación: lo difícil

“There are only two hard things in Computer Science: cache invalidation and naming things.” — Phil Karlton

Tres estrategias de invalidación:

TTL only

Dejar que expire. Simple, puede ser suficiente para datos no críticos. No funciona cuando la actualidad del dato importa.

Invalidación explícita en escritores

Cada código que escribe en la base de datos invalida también las entradas de caché relacionadas.

def update_user(user_id, data):
    db.update(...)
    redis.delete(f"user:{user_id}")
    redis.delete(f"user_list:active")  # invalidar queries relacionadas

Requiere disciplina y documentación: cualquier escritor que omita la invalidación introduce inconsistencias.

Event-based invalidation (CDC)

Un log de cambios en la base de datos (CDC) dispara eventos que invalidan el caché. Más desacoplado, pero añade complejidad operativa — adecuado para sistemas con múltiples escritores o alta carga.

Patrones específicos de Redis

Cuatro features nativas que marcan la diferencia en producción:

• SCAN en lugar de KEYS — KEYS bloquea el servidor completo en bases grandes.
• Pipelines para batch de operaciones — 100 comandos en un pipeline reducen 100 RTTs a 1.
• Scripts Lua para operaciones atómicas complejas (ej. “incrementa este contador y devuelve el valor si < umbral”).
• Estructuras adecuadas: Sorted Set para leaderboards, HyperLogLog para cardinalidad aproximada, Stream para logs de eventos, GEO para geolocalización.

Para patrones relacionados de mensajería asíncrona, ver RabbitMQ para colas de mensajes. En backends con Rust, los clientes de Redis integran bien con tokio y axum mediante redis-rs. La observabilidad con Grafana Stack permite monitorizar tasa de hit, latencia y memoria de Redis con dashboards predefinidos.

Cuándo no usar caché

Tres señales de que el caché no es la respuesta:

• Tasa de hit baja (<50%). El caché solo añade latencia y complejidad.
• Datos que cambian tan rápido que TTL sería <1s. El overhead supera el valor.
• Datos únicos por petición (búsquedas complejas con parámetros muy variables). No hay oportunidad de reuso.

Conclusión

Redis es una herramienta poderosa, pero no mágica. Los equipos que le sacan partido han invertido en diseño consciente de patrón, TTL adecuado al dominio, invalidación bien orquestada y defensa contra thundering herd. Sin esos fundamentos, “meter Redis” frecuentemente empeora los sistemas en lugar de mejorarlos.

1. Redis