El problema fundamental que aborda GitHub es la escalabilidad de sistemas de control de versiones distribuidos bajo cargas de trabajo extremas, específicamente aquellas generadas por el desarrollo de software asistido por agentes. Este paradigma introduce un volumen sin precedentes de operaciones Git, con millones de commits diarios y miles de agentes operando concurrentemente en un solo repositorio. La arquitectura tradicional de Git, y por extensión la infraestructura de GitHub, no fue diseñada para este nivel de concurrencia y throughput, especialmente en operaciones de escritura.
Históricamente, los sistemas de control de versiones han evolucionado desde modelos centralizados (como CVS o Subversion) a distribuidos (Git, Mercurial) para mejorar la resiliencia, la colaboración offline y el rendimiento local. Sin embargo, la centralización de la "fuente de verdad" en plataformas como GitHub introduce desafíos de escalabilidad en el punto de convergencia. La explosión de agentes de IA operando en bucles cerrados de commit/checkpoint expone las limitaciones inherentes a los protocolos de consenso y durabilidad que acoplan la replicación de datos con la capacidad de servicio, un problema clásico en sistemas distribuidos que buscan balancear la consistencia, disponibilidad y tolerancia a particiones (CAP theorem).
La necesidad de una nueva arquitectura surge ahora porque la escala de las operaciones de Git ha crecido exponencialmente, con un aumento de 5x en commits y 4x en merges en un año. Las latencias que antes eran imperceptibles para humanos se convierten en cuellos de botella críticos para agentes, y el fan-out de lecturas (CI/CD, escaneo de código) multiplica cada escritura en miles de lecturas. Esto exige una reevaluación de cómo se gestiona la durabilidad y la consistencia global sin sacrificar el throughput de escritura ni la latencia de commit.
Arquitectura del Sistema
La arquitectura actual de GitHub para repositorios Git se basa en "Spokes", donde cada repositorio se almacena como una copia completa en los discos locales de varios fileservers (típicamente cinco). Estos discos locales proporcionan baja latencia para operaciones Git nativas, y las copias ofrecen redundancia y distribuyen la carga de lectura. Las actualizaciones de referencias (pushes) utilizan un protocolo de commit de tres fases basado en quórum para asegurar la consistencia del estado del repositorio.
El desafío principal de esta arquitectura es que el mecanismo de durabilidad (múltiples copias en disco) es el mismo que el de escalabilidad. Cada réplica participa en cada escritura, lo que significa que un push es tan rápido como la réplica más lenta. Añadir réplicas para absorber carga de lectura ralentiza las escrituras, creando un trade-off insostenible para cargas de trabajo de alta concurrencia. La pérdida de una réplica reduce la capacidad de lectura, y la pérdida de quórum detiene las escrituras por completo.
La nueva arquitectura propuesta desacopla la durabilidad del almacenamiento de la capa de cómputo. El almacenamiento duradero y autoritativo de los datos del repositorio se traslada a Azure Blob Storage, que proporciona durabilidad y replicación a escala de Azure. La capa de cómputo se compone de "workers" ligeros y efímeros que cachean datos para servir solicitudes Git. Estos workers pueden añadirse o eliminarse dinámicamente según la demanda, escalando la capacidad de lectura de forma independiente sin afectar las escrituras. Las operaciones de mantenimiento intensivas, como la compactación y la recolección de basura, se mueven fuera de la ruta de servicio y se ejecutan directamente contra el almacenamiento duradero por workers separados, evitando que ralenticen las operaciones en vivo. El camino crítico de un push se reduce a la actualización de la referencia, que es la única parte que requiere coordinación, mientras que el almacenamiento de objetos subyacentes y otras validaciones pueden ocurrir en paralelo.
Flujo de Push en la Arquitectura Actual
- 1 Cliente Git Inicia un 'git push' con nuevas referencias y objetos.
- 2 Fileserver Primario Recibe el push, inicia protocolo de commit de 3 fases.
- 3 Fileservers Secundarios Reciben y aplican la actualización de referencia y objetos.
- 4 Quórum Se alcanza el quórum de réplicas para durabilidad y consistencia.
- 5 Fileserver Primario Confirma el push al cliente. Actualiza estado visible.
Flujo de Push en la Nueva Arquitectura
- 1 Cliente Git Inicia un 'git push'.
- 2 Compute Worker Recibe el push. Valida objetos y escanea secretos (en paralelo).
- 3 Capa de Coordinación Actualiza la referencia en el almacenamiento duradero (camino crítico).
- 4 Compute Worker Confirma el push al cliente.
- 5 Azure Blob Storage Almacena objetos de forma duradera y replicada.
- 6 Workers de Mantenimiento Realizan compactación y GC en segundo plano contra Blob Storage.
| Capa | Tecnología | Justificación |
|---|---|---|
| storage | Azure Blob Storage | Almacenamiento duradero y autoritativo de los datos del repositorio Git. Proporciona replicación y durabilidad a escala de hyperscaler, desacoplando esta responsabilidad de la capa de cómputo. |
| compute | Custom Compute Workers | Servir solicitudes Git (lecturas y escrituras). Son ligeros, efímeros y cachean datos. Se escalan independientemente de la durabilidad para absorber picos de carga. |
| orchestration | Internal Orchestration System | Gestionar el ciclo de vida de los Compute Workers, escalándolos dinámicamente según la demanda de tráfico para optimizar la capacidad y el costo. |
| data-processing | Custom Maintenance Workers | Ejecutar tareas de mantenimiento intensivas como compactación y recolección de basura directamente contra Azure Blob Storage, fuera de la ruta crítica de servicio. |
Trade-offs
Ganancias
- ▲▲ Write Throughput
- ▲ Read Scalability
- ▲ Recovery Time from Failures
- ▲ Resource Utilization (Compute)
Costes
- ▲ Architectural Complexity
- △ Data Transfer Costs (Storage)
Fundamentos Teóricos
Este rediseño arquitectónico aborda directamente el problema fundamental de la escalabilidad de sistemas distribuidos, un tema central en la investigación académica desde hace décadas. La decisión de desacoplar el almacenamiento duradero de la capa de cómputo es una aplicación directa del principio de "separación de preocupaciones" y del patrón de "storage-compute separation", ampliamente estudiado en bases de datos distribuidas y sistemas de archivos en la nube. Este patrón permite escalar recursos de cómputo y almacenamiento de forma independiente, optimizando la utilización y la resiliencia.
El problema de la consistencia y la durabilidad en sistemas distribuidos se formaliza en el teorema CAP (Consistency, Availability, Partition Tolerance) de Eric Brewer (2000). La arquitectura actual de GitHub, con su protocolo de commit de tres fases y quórum, prioriza la consistencia fuerte (C) y la tolerancia a particiones (P) a expensas de la disponibilidad (A) durante fallos de quórum o alta latencia de escritura. La nueva arquitectura, al mover la durabilidad a un servicio como Azure Blob Storage, delega la gestión de C, A y P a un sistema de almacenamiento de objetos diseñado para alta disponibilidad y durabilidad, permitiendo a la capa de cómputo enfocarse en la disponibilidad y el rendimiento de las operaciones Git. Esto se alinea con la evolución de sistemas distribuidos que buscan "eventual consistency" o "causal consistency" para mejorar la disponibilidad y el rendimiento, mientras que las operaciones críticas que requieren consistencia fuerte se limitan a un conjunto mínimo de datos (en este caso, la actualización de la referencia Git).
La optimización del camino crítico de escritura, al permitir que la mayoría del trabajo (almacenamiento de objetos, validaciones) ocurra en paralelo, es una aplicación del principio de "optimistic concurrency control" y de la minimización de la sección crítica, conceptos fundamentales en la teoría de sistemas operativos y bases de datos. La idea de mover el mantenimiento (compactación, GC) fuera de la ruta de servicio es un patrón común en sistemas de almacenamiento de alto rendimiento, como los basados en LSM-trees (Log-Structured Merge-trees), donde las operaciones de compactación en segundo plano son esenciales para mantener el rendimiento de escritura y lectura sin bloquear las operaciones en primer plano.