Una clave popular de la caché expira y cientos de peticiones golpean la base de datos a la vez. ¿Cómo lo evitas?

Evita la estampida con single flight: la primera petición que falla toma un bloqueo corto y recalcula mientras las demás esperan un momento o sirven el valor rancio. Combínalo con servir rancio mientras revalidas, de modo que una entrada expirada se siga sirviendo mientras un refresco corre en segundo plano, y añade jitter a los tiempos de vida para que las claves creadas juntas no expiren juntas. Para claves calientes conocidas, refresca de forma proactiva antes de que expiren.

El patrón es una estampida: una clave caliente expira y todas las peticiones concurrentes fallan en el mismo instante, así que todas ejecutan la misma consulta cara. El arreglo central es single flight, donde el primer fallo adquiere un bloqueo de vida corta sobre la clave y hace el trabajo, y el resto o espera al resultado o recibe el valor rancio un momento. Eso lo combino con expiración blanda: guardo un tiempo lógico de refresco dentro del valor y mantengo el tiempo de vida duro más largo, así que una entrada pasada de su hora de refresco se sigue sirviendo mientras un trabajador la recalcula por detrás. Los usuarios no ven la latencia en absoluto. Después jitter, porque si un despliegue calienta mil claves con el mismo tiempo de vida de cinco minutos, expiran juntas y me llevo la estampida en toda la caché de golpe. La pregunta mayor que viene después es qué pasa cuando la caché está completamente vacía, tras un reinicio o un failover. Quiero que la base de datos sobreviva a eso, así que hago pruebas de carga con la caché desactivada al menos una vez.