El incidente en Dropbox no fue un fallo catastrófico, sino una degradación progresiva del rendimiento y un riesgo operacional creciente debido al tamaño de su monorepo Git. La causa raíz no fue el volumen de código o binarios, sino una interacción inesperada entre la estructura de directorios de los archivos de internacionalización (i18n) y la heurística de compresión delta predeterminada de Git. Git, al buscar similitudes para la compresión, utiliza los últimos 16 caracteres de la ruta del archivo. En el caso de Dropbox, la estructura 'i18n/metaserver/[language]/LC_MESSAGES/[filename].po' hacía que el código de idioma apareciera antes, llevando a Git a comparar archivos de diferentes idiomas, generando deltas ineficientes y, por ende, 'pack files' desproporcionadamente grandes.
Las salvaguardas fallaron porque la monitorización inicial se centró en el contenido (archivos grandes, dependencias) en lugar de la mecánica interna de Git. La tasa de crecimiento del repositorio, aunque anómala, no se vinculó inmediatamente a un problema estructural de compresión. Además, la dependencia de una plataforma gestionada como GitHub Enterprise Cloud significó que una solución local no era suficiente; la optimización debía ser aplicada en los servidores de GitHub, lo que requirió una estrecha colaboración y un entendimiento profundo de las limitaciones y capacidades de la plataforma.
La cascada de fallos se manifestó como una degradación lenta pero constante: tiempos de clonación excesivos, impactando la incorporación de nuevos ingenieros y la eficiencia de los pipelines de CI (que a menudo requieren clones frescos). Esto, a su vez, aumentó la probabilidad de timeouts en sistemas internos y generó un riesgo inminente de alcanzar el límite de tamaño de 100GB de GitHub, lo que podría haber provocado una interrupción significativa del desarrollo. La solución implicó un 'repack' agresivo del repositorio con parámetros de compresión ajustados, aplicado de forma controlada y gradual en la infraestructura de GitHub.