El incidente en Magic Pocket de Dropbox fue causado por un efecto secundario no intencionado de un nuevo servicio, 'Live Coder', que alteró la forma en que se colocaban los datos. Aunque el servicio estaba diseñado para reducir la amplificación de escritura, introdujo una fragmentación severa al crear volúmenes de almacenamiento con una cantidad extremadamente baja de datos vivos. Esta 'configuration drift' en la distribución de datos no fue detectada a tiempo, permitiendo que se acumulara una gran cantidad de volúmenes ineficientes.
La salvaguarda principal, la estrategia de compactación L1 existente, falló en mitigar el problema porque estaba optimizada para un estado estacionario donde la mayoría de los volúmenes estaban casi llenos y la fragmentación era gradual. L1 no estaba diseñada para manejar una 'long tail' de volúmenes severamente sub-llenos, lo que resultó en una incapacidad para reclamar espacio a la velocidad necesaria. Esto llevó a un aumento significativo en el overhead de almacenamiento, impactando los costos de infraestructura y la eficiencia.
La resolución implicó un replanteamiento de la estrategia de compactación. Se introdujeron dos nuevas estrategias, L2 y L3, para abordar diferentes rangos de llenado de volúmenes. L2 utilizó programación dinámica para consolidar volúmenes moderadamente sub-llenos, mientras que L3 se centró en drenar los volúmenes más dispersos utilizando el servicio Live Coder como pipeline de streaming. Además, se implementaron controles dinámicos para el umbral de elegibilidad de compactación, ordenamiento de candidatos y límites de tasa para proteger los sistemas de metadatos y la red, que resultaron ser cuellos de botella críticos. La falta de visibilidad temprana sobre la distribución de llenado de volúmenes y el rendimiento de la compactación contribuyó a la prolongación del incidente.