Caché en aplicaciones: tiempos de expiración, invalidación y protección frente a la avalancha

Qué es

En el patrón «cache-aside», la aplicación consulta primero la caché; ante un fallo de caché, lee la fuente, guarda el resultado con un tiempo de expiración y lo entrega. Redis documenta los componentes básicos: EXPIRE establece un plazo tras cuyo vencimiento la clave se elimina automáticamente, y SET con la opción NX solo escribe si la clave aún no existe, lo cual constituye la base de un bloqueo simple. A nivel de HTTP, RFC 9111 regula con max-age el mismo principio de una frescura limitada; las cachés de aplicación no siguen ninguna norma, y sus reglas se definen por cuenta propia.

Por qué importa

Una caché reduce la carga y la latencia, pero una entrada obsoleta tras una operación de escritura es un error de corrección difícil de reproducir: solo se manifiesta en la ventana entre la escritura y la expiración, y desaparece al intentar reproducirlo. Por eso la estrategia de invalidación forma parte del diseño, no es una corrección posterior.

Cómo aplicarlo

• Determinar, por clase de dato, cuánto puede envejecer un valor, y fijar la expiración en función de ello; un plazo corto limita el daño de cualquier invalidación olvidada.
• Al escribir, borrar las claves afectadas en lugar de sobrescribirlas: el borrado es idempotente y no puede dejar atrás un valor más antiguo cuando dos escritores se adelantan uno a otro. Un lector al que una escritura le adelanta entre la lectura de la base de datos y la escritura en caché puede igualmente dejar un valor obsoleto; esa ventana solo queda acotada por el tiempo de expiración.
• Incluir un identificador de versión o de esquema en la clave (kunde:v3:123), para que un despliegue con una nueva estructura de valores no lea entradas antiguas; las antiguas expiran por sí solas.
• Tener en cuenta las claves derivadas: si un objeto cambia, también se ven afectadas las listas, los contadores y los resultados de búsqueda que lo contienen. O bien borrar también sus claves, o bien asignarles un plazo más corto.
• Evitar la avalancha («stampede»): cuando expira una clave activa, solo una solicitud debería consultar la fuente. Con SET sperre:<schlüssel> 1 NX EX 5, un proceso obtiene el derecho de recarga; los demás esperan brevemente o entregan el valor antiguo aún disponible. La documentación de Redis llama a SET … NX EX un bloqueo simple, y remite a Redlock para bloqueos tolerantes a fallos; para la protección frente a la avalancha, donde un fallo solo significa un segundo proceso de recarga, la forma simple es suficiente.
• Almacenar en caché los resultados negativos («no encontrado») con un plazo corto, cuando muchas solicitudes apuntan a claves inexistentes.
• Medir la tasa de aciertos y la carga sobre la fuente; una caché sin aciertos solo cuesta latencia adicional en cada fallo.

Trampas

Datos dependientes del usuario bajo una clave compartida. Tratar la caché como un almacenamiento permanente, aunque un reinicio la vacíe. Tiempos de expiración que se establecen y se comprueban en distintos hosts con relojes desincronizados. Un bloqueo sin tiempo de expiración que, tras una caída del proceso de recarga, nunca vuelve a liberarse.