500 peticiones simultáneas a Redis: 213 se saltaron el caché y golpearon la API

El patrón cache-aside es de primero de backend: se consulta Redis, si no hay nada se llama al origen y se guarda la respuesta para la próxima. Un desarrollador montó exactamente eso con una API del tiempo en Go y un Redis local, lanzó 500 peticiones concurrentes con k6 y vio cómo 213 se saltaban el caché y llamaban al servicio externo al mismo tiempo.

Cómo estaba montado

La prueba tiene dos piezas. La primera es una API falsa del tiempo que escucha en el puerto 3000 y devuelve un JSON desde disco, para no chocar con el límite de peticiones del servicio real. La segunda es el backend que atiende a los usuarios en el 8080: recibe la ciudad por query string, busca esa clave en Redis y, si hay acierto, responde con un Cache HIT. Si no la encuentra, hace un http.Get contra el upstream, guarda el resultado en Redis con un TTL de 10 minutos y contesta con un Fetched from API.

Para medirlo escribió un test de k6 con dos escenarios. El primero, primer, hace una única petición para poblar la clave. El segundo, stampede, arranca justo cuando el TTL acaba de expirar y dispara 500 peticiones con 500 usuarios virtuales en una ventana de 10 segundos. Dos contadores personalizados leen la cabecera X-Cache de cada respuesta para separar aciertos de fallos.

Qué salió

287 aciertos y 213 fallos. Las 500 peticiones llegaron con milisegundos de diferencia, así que las primeras 213 comprobaron la clave, la encontraron vacía y salieron a por los datos a la vez. Las otras 287 llegaron cuando el valor ya estaba escrito en Redis y se sirvieron de ahí. El propio autor lo dice: todas esas 213 peticiones hicieron el mismo trabajo para traer exactamente el mismo dato.

El problema no es el caché, es la ventana. Y las consecuencias dependen de qué haya detrás. Contra una API del tiempo con límite de peticiones, eso es un bloqueo inmediato. Contra una base de datos, son 213 consultas idénticas ejecutándose en paralelo por un dato que ya estaba calculado; en un servidor pequeño, eso se nota.

Es el thundering herd de manual, o cache stampede, y llevaba décadas documentado. Lo que aporta el experimento es verlo aparecer con una configuración mínima y con números concretos en lugar de con un diagrama. Cualquiera que tenga un caché delante de un servicio caro está a una expiración de TTL de reproducirlo.

El autor no llega a plantear la salida en lo que publica: queda en el diagnóstico. Las vías habituales pasan por que solo una petición pueda recomponer la clave mientras el resto espera, por repartir las expiraciones con algo de aleatoriedad o por servir el valor viejo mientras se refresca en segundo plano. Elegir una u otra depende de cuánto duela devolver un dato con unos segundos de más.