La plataforma GitHub se enfrenta a un crecimiento sin precedentes en la intensidad de las operaciones en el sistema Git, impulsado por la proliferación de software y agentes de inteligencia artificial (AI Agents) que generan flujos intensos y continuos de modificaciones y actualizaciones. Para hacer frente a las limitaciones físicas de la capacidad energética en los centros de datos tradicionales y las cadenas de suministro, la empresa ha revelado un plan arquitectónico que hasta ahora ha llevado a trasladar copias del 99,99999% de sus repositorios para que residan conjuntamente entre sus propios centros de datos y la nube de Microsoft Azure.
El obstáculo de la latencia y el bloqueo total del repositorio
GitHub explicó que los repositorios más utilizados y modificados de la plataforma —que representan el diminuto porcentaje restante (0,00001%)— se enfrentaban a una barrera técnica consistente en la latencia de red. Al transferir los datos a la región central de Azure en Estados Unidos (Central US), situada a unas mil millas de los centros de datos de la plataforma, cada conexión de red añade un tiempo de retardo de aproximadamente 25 milisegundos en el viaje de ida y vuelta.
En la antigua arquitectura del sistema de sincronización y consenso "Spokes", cualquier nueva operación de escritura requería imponer un bloqueo global en todo el repositorio (Repository-wide lock) hasta que respondieran las réplicas. Debido a la retención del bloqueo global, la réplica más lenta en la red se convirtió en la que determinaba el tiempo de respuesta y el límite máximo de rendimiento de todo el repositorio, provocando la congestión de los repositorios activos que reciben envíos de código frecuentes por parte de desarrolladores y agentes de inteligencia artificial.
Consenso basado en referencias individuales
Para superar esta congestión, GitHub rediseñó el mecanismo de consenso aplicando su primer principio arquitectónico: "reducir la coordinación y eliminar el bloqueo innecesario". En lugar de cerrar todo el repositorio durante una actualización, el ámbito de consenso y bloqueo pasó a aplicarse exclusivamente a referencias individuales (Per-reference serialization) como ramas (Branches) o etiquetas (Tags).
Dado que la mayoría de las operaciones de escritura simultáneas ejecutadas por desarrolladores o agentes de IA se dirigen a diferentes ramas, las modificaciones ya no tienen que esperar unas por otras en una sola cola. Las pruebas internas realizadas por la empresa bajo cargas del mundo real demostraron un aumento de 3 a 4 veces en la capacidad de absorción de operaciones de escritura, con una notable disminución en el tiempo de latencia.
Separación del almacenamiento del procesamiento y generalización del almacenamiento de objetos
La segunda fase incluye la aplicación del segundo principio arquitectónico: "separar el almacenamiento de las capacidades de procesamiento" (Decoupling storage from compute). La mayoría de los repositorios de Git se caracterizan por una gran densidad de operaciones de lectura en comparación con las de escritura, con una proporción que oscila entre 100 y 1.000 operaciones de lectura por cada operación de escritura. En la arquitectura anterior, las lecturas y escrituras competían por los mismos recursos y memoria.
Para solucionar esto, GitHub incorporó el almacenamiento de objetos (Azure Blob Storage) como miembro virtual en el consejo de consenso, denominado "réplica de escritura virtual" (Virtual Write Replica). Esta réplica actúa como una cadena transitoria que agrupa las transacciones y transmite las modificaciones de manera sostenible al almacenamiento en la nube. Una vez confirmado el almacenamiento, la plataforma puede lanzar un número ilimitado de réplicas de lectura virtuales (Virtual Read Replicas) escalables bajo demanda, las cuales actualizan su memoria caché en segundo plano sin afectar la velocidad de escritura de datos o la sincronización.
¿Qué cambia en la práctica para la arquitectura de desarrollo de software?
Esta transformación de ingeniería en GitHub refleja cómo se rediseñan los grandes sistemas distribuidos para soportar la naturaleza del trabajo automatizado basado en inteligencia artificial, y los impactos prácticos más destacados se pueden resumir en lo siguiente:
- Elevar el límite de productividad: Permitir que los agentes de inteligencia artificial y los desarrolladores realicen envíos simultáneos intensivos sin bloqueos (Lock) en los repositorios principales.
- Flexibilidad en el escalado de lectura: La capacidad de aumentar los servidores de lectura y asignarles memoria caché de forma independiente sin necesidad de pasar por pesados procedimientos de consenso.
- Continuidad del sistema principal: Actualizar los componentes internos del sistema "Spokes", que ejecuta más de 100 mil millones de operaciones diarias sin necesidad de detener el servicio ni sacrificar la integridad de los datos.