Cómo Meta mantiene la consistencia de caché usando invalidación de caché (traducción)

Inconsistencia de caché

• el servidor de caché envía una solicitud por x a la db y, antes de que la respuesta de la db con x=42 llegue a la caché
  • desde fuera se actualiza a x=43 y, mediante invalidación, se le entrega x=43 a la caché
  • la caché recibe x=43 y lo aplica
  • la respuesta con x=42 llega tarde y se aplica
• el problema anterior se puede resolver agregando una versión a los datos
• pero incluso si se agrega una versión, si ocurre una eviction de x=43, x=42 podría aplicarse

Polaris: servicio de medición de inconsistencia de caché

• proceso de funcionamiento
  • Polaris también recibe eventos de invalidación
  • cuando recibe un evento, consulta a todos los servidores de caché para verificar si tienen la versión anterior
  • si la caché tiene la versión anterior, lo considera una inconsistencia y lo vuelve a poner en cola para poder reintentar
    • porque el evento de invalidación puede llegar tarde al servidor de caché
  • si pasa cierto tiempo (1 minuto, 3 minutos, 5 minutos, etc.), envía una alerta de inconsistencia
• métrica
  • muestra una métrica de si las escrituras en caché equivalentes a N nueves durante los últimos M minutos fueron consistentes
  • si son 10 nueves durante 5 minutos, se puede saber que 1 escritura de caché de cada 10 mil millones fue inconsistente en los últimos 5 minutos

Librería de logging para depurar la inconsistencia de caché

• no es posible registrar todas las escrituras en caché
  • porque la caché originalmente tiene una carga dominada por lecturas, pero por el "logging" pasaría a tener una carga dominada por escrituras
• por eso crearon una librería que permite hacer logging en una ventana de tiempo justo después de que ocurre una invalidación
• insertaron la librería en todos los servicios involucrados en la invalidación
• mediante el logging, cuando ocurre una inconsistencia, se puede reconstruir como timeline el proceso hasta que ocurrió