Invalidación de caché sin dolor de cabeza
· 7 min
La invalidación de caché es famosa por ser "uno de los dos problemas difíciles" de la computación, pero la forma más común en que falla en la práctica no es elegir el algoritmo equivocado, es nunca decidir explícitamente quién es responsable de invalidar qué.
El TTL solo es una apuesta, no una estrategia
Un TTL corto mantiene el dato fresco a costa de golpear la base de datos con más frecuencia; un TTL largo ahorra carga a costa de servir datos desactualizados por más tiempo. Usar solo TTL funciona bien cuando ese período de inconsistencia es genuinamente aceptable para el caso de uso, y se convierte en un problema silencioso cuando no lo es, porque el sistema nunca avisa que está sirviendo algo viejo.
Invalidación por evento: quien escribe avisa
En la invalidación por evento, el propio código que modifica el dato es responsable de borrar o actualizar la entrada de caché correspondiente, dando consistencia casi inmediata. El costo es acoplamiento: cada ruta de escritura necesita saber qué claves de caché dependen de ese dato, y olvidar una de ellas es la forma más común en que este patrón falla en silencio.
Cache stampede: cuando todos golpean la base de datos a la vez
Cuando expira una clave muy accedida, múltiples solicitudes concurrentes pueden encontrar el miss al mismo tiempo y disparar todas juntas contra la base de datos para repoblar la caché, una pequeña expiración se convierte en un pico real de carga. Las mitigaciones más comunes son coalescer solicitudes (solo una de ellas recalcula de verdad, las demás esperan el resultado) y la expiración anticipada probabilística, renovando la entrada un poco antes del plazo real para repartir la carga en el tiempo.
Cache-aside vs write-through
En el patrón cache-aside, la aplicación consulta la caché, cae a la base de datos en el miss y llena la caché después, simple, pero con una ventana en la que caché y base de datos pueden divergir. En write-through, toda escritura pasa por la capa de caché, que mantiene ambas sincronizadas siempre, más consistente, a costa de más complejidad en la capa de escritura.
La pregunta que evita el dolor de cabeza
Antes de elegir una estrategia de invalidación, vale la pena decidir explícitamente, para cada dato en caché, quién es responsable de invalidarlo y bajo qué evento. La mayoría de los bugs de caché no vienen del algoritmo equivocado, vienen de que esa responsabilidad nunca se decidió de verdad.