GitHub ha trasladado copias del 99,99999 % de sus repositorios a Azure, al tiempo que conserva copias en sus propios centros de datos. Los repositorios restantes se encuentran entre los más concurridos de la plataforma, y la latencia de red entre regiones ha dificultado su migración. La empresa afirma que cambiar la forma en que coordina las escrituras ayudará a trasladarlos y respaldará un cambio hacia una infraestructura diseñada para el creciente tráfico de desarrolladores y agentes de IA.
La migración comenzó cuando una copia de un repositorio llegó a la región Centro de EE. UU. de Azure en agosto de 2025. Actualmente, la mayoría de los repositorios tiene dos de sus cinco réplicas en Azure, que gestiona aproximadamente la mitad del tráfico de Git. GitHub decidió trasladar los datos antes de cambiar la arquitectura de almacenamiento, aludiendo a la importancia de las operaciones de Git y a los riesgos de cambiar al mismo tiempo tanto la plataforma de alojamiento como la arquitectura.
En el diseño actual, un quórum de escritura espera a que respondan todas las réplicas en buen estado, aunque basta una mayoría para confirmar una escritura. Como se mantiene un bloqueo de todo el repositorio hasta que se completa la escritura, la réplica más lenta puede limitar tanto la latencia como el rendimiento. Dado que las réplicas de Azure están a unas 1.000 millas de los centros de datos de GitHub, un viaje de ida y vuelta por la red tarda alrededor de 25 milisegundos, y las escrituras requieren varios viajes.
El cambio que propone GitHub consiste en coordinar las escrituras por referencia, en lugar de hacerlo en todo el repositorio. Las referencias incluyen punteros a ramas, y la empresa afirma que las actualizaciones de distintas referencias normalmente no dependen unas de otras. Con el nuevo enfoque, las escrituras en una misma referencia siguen esperando unas a otras, mientras que las escrituras en referencias distintas pueden realizarse en paralelo. En pruebas internas con tráfico realista, GitHub informa de un rendimiento entre 3 y 4 veces mayor para las escrituras en referencias distintas, con menor latencia.
El cambio también permite una vía independiente para escalar las lecturas. GitHub afirma que los repositorios suelen recibir entre 100 y 1.000 lecturas por cada escritura, pero actualmente ambos tipos de tráfico utilizan las mismas réplicas y compiten por los recursos. El siguiente paso es incorporar Azure Blob Storage al quórum de escritura mediante una «réplica virtual». Este nodo efímero transmite las escrituras entrantes al almacenamiento de objetos, y una escritura solo se confirma una vez que queda almacenada allí de forma duradera.
La réplica virtual de escritura no atiende lecturas. En su lugar, GitHub puede crear réplicas virtuales de lectura cuando las necesite, precalentar sus cachés desde Blob Storage y atender el tráfico de lectura sin que se unan al quórum. En pruebas internas de carga, GitHub afirma que su sistema de pruebas alcanzó sus propios límites antes de encontrar un techo para estas réplicas. La empresa señala que la reconciliación en segundo plano podría no ser adecuada para todas las cargas de lectura y que se necesitan más mejoras para aumentar el rendimiento de escritura por encima de los límites del quórum.
GitHub afirma que el siguiente reto consiste en ordenar la pequeña cantidad de datos del repositorio que requiere coordinación, mientras se almacenan objetos Git inmutables sin exigir que las réplicas lleguen a un acuerdo. La empresa tiene previsto describir la arquitectura final que pretende alcanzar en una próxima publicación y en GitHub Universe.
Fuentes: GitHub Blog.