A lo largo del último año, a medida que el tráfico de Git crecía de forma exponencial, casi todos los repositorios Git de GitHub comenzaron a vivir en dos lugares a la vez: los centros de datos propios de GitHub y Azure. Los repositorios más activos siguen limitados por un solo factor: un tiempo de ida y vuelta de 25 ms entre regiones.
En una publicación anterior, GitHub expuso dos principios detrás de su arquitectura de almacenamiento de nueva generación: minimizar la coordinación y desacoplar el almacenamiento del cómputo. Esta publicación examina el puente entre el diseño antiguo y el nuevo. Un cambio en la forma en que el quórum serializa las escrituras lleva a los repositorios más activos a Azure, y ese mismo paso abre la puerta a réplicas que no conservan estado persistente propio.
El momento de la migración estuvo determinado por el cambio hacia la IA agéntica: un tráfico que crecía rápidamente, un límite estricto en la capacidad eléctrica de los centros de datos de GitHub y de su región circundante, y restricciones físicas en la cadena de suministro. La capacidad restante dio tiempo suficiente para migrar con seguridad, pero no para hacerlo con calma. Como las operaciones de Git son un servicio de Nivel 0 del que depende casi todo en GitHub, los datos tenían que moverse primero, y la arquitectura evolucionaría una vez que llegaran. La primera copia de un repositorio llegó a la región Central US de Azure en agosto de 2025. Hoy, la mayoría de los repositorios tiene dos de sus cinco réplicas en Azure, y Azure atiende alrededor de la mitad del tráfico de Git.
El 0,00001 % restante de los repositorios plantea un problema más difícil. En la arquitectura actual, una escritura espera a que responda cada réplica sana, de modo que la réplica más lenta determina tanto la latencia como el rendimiento. Una réplica en la región de Azure de destino está a unas 1.000 millas y cada escritura requiere varios viajes de ida y vuelta. La respuesta está en minimizar la coordinación: los requisitos de consistencia de Git se aplican a cada referencia por separado, y las actualizaciones de referencias distintas normalmente no dependen unas de otras, por lo que no necesitan serializarse.
Fuente: Hacker News · Resumido por HeadlinesBriefing