El puente de GitHub hacia una infraestructura Git a escala de agentes: quórum por referencia y réplicas virtuales

GitHub explica en su blog de ingeniería cómo está reconstruyendo su infraestructura Git, mientras el servicio sigue funcionando, para soportar el crecimiento del tráfico generado por agentes de IA. El artículo, firmado por dos ingenieros de GitHub, describe el puente entre el diseño actual y la arquitectura de almacenamiento de nueva generación. Forma parte de una serie que continúa un post anterior: se anuncia un post final para la semana siguiente, coincidiendo con GitHub Universe.

Según el texto, el 99,99999 % de los repositorios de Git en GitHub ya vive en dos sitios a la vez: los centros de datos propios y Azure. El calendario y la forma de la migración los marcaron tres factores: el crecimiento rápido del tráfico por el cambio hacia lo agéntico, un techo duro de capacidad eléctrica en los centros de datos y su región geográfica, y restricciones físicas de la cadena de suministro. La capacidad restante daba tiempo para migrar con seguridad, pero no para hacerlo despacio. Por eso GitHub decidió cambiar primero el lugar donde residen los datos y evolucionar la arquitectura después. Cambiar a la vez la arquitectura de almacenamiento y la plataforma de alojamiento, con ese crecimiento, suponía demasiado riesgo.

Las operaciones Git son un servicio de Tier 0: casi todo en GitHub depende de los datos de los repositorios, así que datos, servicios y dependencias tenían que moverse primero. 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 aproximadamente la mitad del tráfico Git. Durante la migración el tráfico sigue a los datos: Spokes, el sistema de almacenamiento de GitHub, usa enrutado preferente hacia una réplica de la misma región y zona de disponibilidad que la petición. Cada réplica que llega a Azure aumenta la proporción de tráfico servible desde allí, hasta que la última réplica llega y la región antigua deja de recibir peticiones.

Quedan fuera de esa migración el 0,00001 % de repositorios, que están entre los más activos de la plataforma. El obstáculo es una latencia de ida y vuelta de unos 25 ms. En la arquitectura actual, un repositorio alojado en varias regiones tiene un techo de rendimiento de escritura más bajo. El quórum de Spokes solo necesita mayoría para confirmar una escritura, pero espera la respuesta de todas las réplicas sanas (hasta un tiempo límite). Así, la réplica sana más lenta fija la latencia de cada escritura. Como cada escritura mantiene un bloqueo a nivel de repositorio hasta confirmarse, también fija el techo de rendimiento. Una réplica en la región de Azure de destino queda a unas 1.000 millas de los centros de datos, y una escritura requiere varias idas y vueltas. Un repositorio cercano a su techo no puede absorber eso en cada escritura serializada y se iría quedando atrás con cada push.

Aquí entra el primer principio, minimizar la coordinación: no serializar lo que no hace falta. Los requisitos de consistencia de Git se aplican a cada referencia por separado. Una vez que el servidor acepta una actualización de una referencia, ningún cliente debe ver después un valor más antiguo, ya sea fast-forward, force push o borrado. Pero las actualizaciones de referencias distintas suelen ser independientes. Por eso GitHub cambia el ámbito del quórum, del repositorio entero a cada referencia individual. Con serialización por referencia solo esperan entre sí las escrituras que compiten por la misma referencia. En la práctica, agentes y desarrolladores suelen empujar a sus propias ramas, de modo que ya no se bloquean unos a otros. Cada escritura sigue sufriendo la latencia entre regiones, pero varias pueden estar en vuelo a la vez. El techo de escritura sube aproximadamente en proporción al número de referencias que se escriben simultáneamente. En pruebas internas con tráfico realista, las escrituras a referencias distintas lograron de forma consistente entre 3 y 4 veces más rendimiento con menor latencia.

El segundo bloque trata de escalar las lecturas por separado. La mayoría de los repositorios tiene un sesgo fuerte hacia la lectura, con entre 100 y 1.000 lecturas por cada escritura. Hoy lecturas y escrituras golpean las mismas réplicas, compiten por los mismos recursos y no pueden escalarse de forma independiente. Al desacoplar almacenamiento y cómputo, los datos del repositorio se guardan de forma duradera en Azure Blob Storage y se actualizan con cada escritura. Así se puede separar el tráfico de lectura del quórum de escritura y escalar el cómputo de cada uno. Las lecturas, por ejemplo, se beneficiarían de mucha más caché en memoria que la actual, pero esa memoria también hace falta para la compactación.

El primer paso es convertir el almacenamiento de objetos en miembro del quórum, de un tipo especial llamado réplica virtual. El cómputo que lo representa es el primer nodo totalmente efímero: actúa de puente hacia el almacenamiento de objetos, transmite las escrituras entrantes y no sirve lecturas. Como es miembro del quórum, una escritura no se confirma hasta ser duradera en el almacenamiento de objetos. Eso añade algo de latencia, pero la serialización por referencia evita que se convierta en cuello de botella de rendimiento. Además, esta réplica virtual de escritura agrupa transacciones sobre referencias disjuntas en un único conjunto de operaciones de red hacia el almacenamiento, de forma que un repositorio ocupado paga una sola ida y vuelta por muchas escrituras concurrentes. Por ahora también se encarga de la compactación, y las réplicas de lectura heredan el estado compactado.

Con ella en marcha se pueden desplegar bajo demanda tantas réplicas virtuales de lectura como necesite un repositorio. Cada una calienta su caché desde Azure Blob Storage y empieza a recibir tráfico de lectura sin unirse al quórum. Usa el almacenamiento de objetos como fuente de verdad y reconcilia en segundo plano su estado local. GitHub afirma que en pruebas internas su arnés de pruebas de carga distribuida encontraba techos de forma rutinaria en la arquitectura actual, mientras que frente a las réplicas virtuales de lectura el arnés alcanzó antes sus propios límites.

El enfoque tiene limitaciones, que según el artículo se resuelven en pasos posteriores. Como la reconciliación es en segundo plano, estas réplicas encajan en algunas cargas de lectura pero no en todas. Para servir cualquier tipo de lectura hay que hacer la reconciliación en línea, obteniendo solo el estado de referencias y los datos que han cambiado desde la última puesta al día de la réplica. Además, aunque el modelo por referencia sube el rendimiento de escritura, el quórum sigue siendo el factor limitante.

Sobre el futuro, los autores recuerdan que Spokes es hoy mucho más que un coordinador de quórum. También es una capa de enrutado y balanceo de carga inteligente, una API unificada que los clientes internos usan para acceder a los datos de los repositorios con bastante más de 100.000 millones de operaciones al día, y un conjunto de sistemas de segundo plano llamados «sweepers» que se ocupan de la ubicación, la reparación y el reequilibrio. Casi todo eso sirve igual en la nueva arquitectura. Sin embargo, GitHub reconoce que el protocolo de confirmación que la llevó a mil millones de repositorios no la llevará a los siguientes mil millones.

El siguiente límite es el rendimiento de escritura. Cada escritura sigue esperando a réplicas que guardan una copia completa del repositorio, aunque muy poco de una escritura necesita realmente ordenarse. Los objetos Git son inmutables y se nombran por su contenido, por lo que pueden almacenarse sin consenso. Lo que queda es pequeño, y lo difícil es ordenarlo lo más rápido posible sin mover el cuello de botella a otro sitio. Hacerlo implica repensar efectos de segundo orden, como dónde vive el estado duradero de las referencias y cómo escalan la compactación y la recolección de basura. La entrega final de la serie, anunciada para GitHub Universe, describirá ese estado final, su efecto en el rendimiento de escritura, los problemas de segundo orden resueltos y por qué seguirá existiendo un pequeño grupo de consenso en algún punto de la pila.

En conjunto, el artículo es una explicación técnica de ingeniería de GitHub sobre una migración a Azure condicionada por el tráfico de agentes. Las cifras de rendimiento citadas (3 a 4 veces más en escrituras a referencias distintas) proceden de pruebas internas de la propia compañía y no hay verificación independiente.