Caché de base de datos: frescura, avalanchas y claves calientes
Una consulta de perfil se repite miles de veces aunque su contenido cambie poco. En el patrón cache-aside, la aplicación busca primero la clave en caché. Un acierto devuelve el valor; un fallo consulta la base de datos y almacena el resultado para la siguiente lectura. La base conserva el papel de fuente de verdad.
El precio de guardar una copia
Si el nombre cambia de rick123 a rick456 en la base, la copia puede seguir mostrando el anterior. Un TTL de cinco minutos limita la vigencia de la entrada, pero no hace que todas las lecturas reflejen instantáneamente cada escritura. Invalidar la clave después de confirmar la actualización acorta ese período.
La invalidación sencilla tampoco elimina todas las carreras. Un lector puede haber obtenido el valor antiguo, otro proceso confirmar la actualización e invalidar y, después, el primer lector volver a guardar su resultado viejo. Según la consistencia requerida, hacen falta versiones, coordinación de escrituras, eventos confiables u otras estrategias. El TTL sigue siendo una red de contención, no una transacción entre sistemas.
Cuando todos fallan a la vez
Al vencer un perfil muy popular, cientos de peticiones pueden consultar simultáneamente la base. Esa avalancha o cache stampede concentra precisamente el trabajo que la caché evitaba. La técnica single flight agrupa recargas por clave: una petición obtiene el dato y las demás esperan o reutilizan el resultado.
La coordinación dentro de un proceso no se extiende automáticamente a todas las réplicas. Una coordinación distribuida necesita tiempo límite, recuperación si el líder falla y cuidado al liberar bloqueos. La espera tampoco debería ser ilimitada.
Jitter y claves calientes resuelven problemas distintos
Añadir variación al TTL —por ejemplo, 300 segundos más un valor aleatorio entre −20 y 20— distribuye vencimientos de distintas claves. No evita por sí solo que una única clave popular concentre recargas. Para esa clave sigue siendo útil agrupar solicitudes o refrescar anticipadamente cuando sea admisible.
Si la entrada no vence y aun así recibe demasiadas lecturas, el problema es una hot key. Réplicas de lectura o cachés locales pueden distribuir trabajo a cambio de más complejidad de frescura. Repartir claves entre shards no divide automáticamente las lecturas de una sola clave.
Qué observar
La tasa de aciertos es útil, pero debe acompañarse de latencia p95/p99, expulsiones por memoria, errores y carga de la base durante recargas. Una caché con muchos aciertos puede seguir fallando si una minoría de misses provoca consultas muy costosas. Diseñarla significa decidir cuánto atraso tolera cada dato y cómo se comporta el sistema cuando deja de acertar.