Cachés y verdades desactualizadas
Intercambia latencia por frescura de forma deliberada y examina las carreras escondidas en la invalidación.
AL TERMINAR, PODRÁS
- Explicar cache-aside y sus modos de falla
- Distinguir la expiración de una garantía estricta de frescura
- Controlar las estampidas y el alcance de las claves de caché
Descripción del diagrama: App → Caché (1. leer); Caché → Base de datos (2. fallo: cargar); App → Base de datos (escribir); Base de datos → Caché (luego invalidar)
Una caché guarda una respuesta reutilizable
Una caché puede reducir la latencia y la carga cuando las respuestas se piden repetidamente y se pueden reutilizar.
En cache-aside (caché al lado), quien lee consulta la caché, carga lo que falta desde la fuente de verdad y luego guarda la respuesta. El diseño necesita una clave, un valor, una política de expiración y un responsable de la invalidación. Incluye en la clave cada entrada que cambie la respuesta, incluido el inquilino o el alcance de permisos cuando corresponda.
Compartir por accidente un resultado específico de un usuario con otros usuarios es una falla de corrección y de seguridad, no simplemente una mala tasa de aciertos.
La invalidación tiene un problema de orden
Supón que un lector obtiene datos viejos, un escritor confirma (commit) datos nuevos e invalida la caché, y luego el lector llena la caché con su resultado viejo.
La caché vuelve a estar desactualizada pese a la invalidación. Un time-to-live (TTL, tiempo de vida) limita cuánto dura esa entrada después de escribirse, pero por sí solo no establece un límite estricto medido desde el cambio original de los datos en todas las carreras posibles. Los valores con versión, las escrituras condicionales o una coordinación más fuerte pueden ayudar, cada uno con sus costos.
Enuncia la promesa de frescura que tus usuarios realmente necesitan.
Una capa rápida puede causar un incidente lento
Cuando expira una clave popular, muchos lectores pueden fallar en la caché a la vez y sobrecargar la base de datos.
Agrupar las peticiones (request coalescing), poner jitter en la expiración o servir un valor desactualizado aceptable durante la actualización puede reducir esta estampida. Decide cómo se comporta el servicio cuando la caché no está disponible: recurrir a la base de datos solo es seguro si la base de datos puede absorber la carga. Monitorea la tasa de aciertos junto con la latencia, las expulsiones y la carga del origen.
En Relay, un estado en caché puede ser aceptable para un panel, mientras que saber quién tiene reservado un trabajo requiere comprobaciones autoritativas más fuertes.
ERROR FRECUENTE
Usar una copia en caché de quién tiene reservado un trabajo, o de su estado, para autorizar una transición de estado crítica puede convertir una desactualización aceptable en pantalla en un error de corrección.
INTÉNTALO TÚ
Escribe en orden los tres pasos de la carrera de relleno con datos viejos. Propón una mitigación e identifica el estado adicional o la coordinación que requiere.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Elige una lectura de Relay que pueda tolerar datos desactualizados, define su expectativa de frescura y deja las transiciones de reserva fuera de esa caché.