Respuesta
Patrón base: cache-aside. Se lee de Redis; si no está, se consulta la base, se guarda con TTL y se devuelve.
Invalidación
- Al escribir: actualizar la base primero y después borrar la clave (no reescribirla), para reducir carreras donde un valor viejo pisa uno nuevo.
- Siempre con TTL como red de seguridad: si falla un borrado, el dato inconsistente expira.
- Si hay varios servicios escribiendo, invalidar por eventos (por ejemplo CDC o mensajes) en vez de depender de que cada uno lo haga.
- Asumir y acordar con negocio que la consistencia es eventual; para datos que no lo toleran (saldos), no cachear o leer de la fuente.
- Lock / single-flight: solo uno recalcula; el resto espera brevemente o sirve el valor anterior.
- Jitter en el TTL: sumar aleatoriedad para que muchas claves no expiren juntas.
- Stale-while-revalidate / expiración anticipada probabilística: guardar un TTL lógico menor al real y refrescar en segundo plano antes de que caduque.
- Precalentar claves críticas tras deploys o reinicios.
val = redis.get(key)
if val is None:
if redis.set(lock_key, token, nx=True, px=5000):
try:
val = db.query()
redis.set(key, val, ex=300 + random.randint(0, 60))
finally:
release_if_owner(lock_key, token) # script Lua atómico
else:
sleep(0.05); return retry_or_stale()Errores comunes
Hablar solo de TTL sin estrategia de invalidación al escribir. Actualizar la caché en vez de borrarla sin considerar carreras, o implementar el lock sin expiración ni verificación de dueño al liberarlo.
Redactado con el asistente Underc0de IA. Actualizado el 15/11/2026. ¿Ves un error? Contanos en el foro.