Brian Celenza, ingeniero de software principal de GitHub, escribió el 6 de octubre en el blog oficial de ingeniería que la empresa está reconstruyendo su capa de almacenamiento de Git. El motivo se expone sin rodeos: los agentes de IA empujaron el tráfico de escritura hasta el límite de la arquitectura anterior. En pruebas internas, la nueva arquitectura eleva el throughput de escritura hasta 35 veces.
El artículo ofrece una serie de cifras de crecimiento del último año:
| Métrica | Dato más reciente | Variación anual |
|---|---|---|
| Eventos Git al mes | 473.300 millones (agosto de 2026) | cerca de 2,2x |
| Pushes al mes | 3.350 millones | 4,9x |
| Commits al mes | 7.380 millones (septiembre de 2026) | más de 5x |
| Ejecuciones de Actions al mes | 3.260 millones (septiembre de 2026) | más de 4x |
| PR fusionados | sin valor absoluto | casi 4x |
El repositorio individual más activo recibió alrededor de 1.000 millones de solicitudes solo en agosto. El artículo describe así el hábito de escritura de los agentes:
"An agent in a tight loop commits or checkpoints after nearly every action" (Un agente que corre en bucle cerrado hace commit o guarda un checkpoint tras casi cada acción.)
La arquitectura anterior se atasca en la escritura
El sistema de almacenamiento de repositorios actual de GitHub se llama Spokes. Por defecto, cada repositorio se guarda como copia completa en los discos locales de varios servidores de archivos, cinco copias en total. Cuando un push actualiza una referencia, el sistema usa un protocolo de commit en tres fases basado en mayoría para garantizar que CI, la web y los clientes de API vean un estado consistente del repositorio.
En este diseño, las réplicas cumplen dos funciones a la vez: evitar la pérdida de datos y repartir las solicitudes de lectura. El costo es que cada réplica debe participar en cada escritura: añadir réplicas permite soportar más lecturas, pero hace la escritura más lenta. En la era dominada por desarrolladores humanos, las lecturas superaban ampliamente a las escrituras, así que esta disyuntiva no era un problema; cuando los agentes elevaron la frecuencia de escritura, el número de réplicas se convirtió en el cuello de botella de la escritura.
La nueva arquitectura se divide en tres partes
La primera parte consiste en reducir la coordinación al mínimo: solo la actualización de referencias necesita consenso entre las partes; el almacenamiento de objetos, la validación y el escaneo de seguridad pasan a procesarse en paralelo.
La segunda parte es separar almacenamiento y cómputo. La persistencia queda a cargo de Azure Blob Storage, y las solicitudes de lectura las atiende un grupo de procesos worker ligeros. El artículo lo expresa así:
"Separating the two lets us scale each one independently" (Separar ambas partes permite escalar cada una de forma independiente.)
La tercera parte aísla el mantenimiento en segundo plano: la compactación y la recolección de basura se ejecutan en procesos worker dedicados, sin competir por recursos con las solicitudes en tiempo real. Los mecanismos de control como la protección de ramas, las revisiones obligatorias, los registros de auditoría y la observabilidad se mantienen.
Un cálculo rápido del volumen de escritura
Con un cálculo aproximado basado en un mes de 30 días, los 7.380 millones de commits equivalen a unos 2.850 por segundo; los 3.350 millones de pushes equivalen a unos 1.290 por segundo, frente a unos 270 hace un año. Si cada push necesitara la participación de las 5 réplicas, la arquitectura anterior tendría que procesar unas 6.500 escrituras de réplica por segundo (estimación, sin contar reintentos ni tareas de mantenimiento).
El aumento de 35 veces en el throughput corresponde a una tasa de crecimiento anual de los pushes de 4,9x, lo que deja, sobre el papel, margen para varios años. La condición es que la curva de crecimiento del tráfico de agentes no se vuelva aún más pronunciada, algo que ni el propio GitHub se atreve a predecir.
Lo que el artículo no explica
El artículo no da un calendario sobre cuántos repositorios ya migraron a la nueva arquitectura ni cuándo se completará el cambio total; tampoco detalla el tamaño del repositorio ni el nivel de concurrencia usados en el benchmark de 35x. Tampoco menciona posibles efectos para los usuarios, como si se ajustarán los límites de tasa.
GitHub sufrió este año varias interrupciones de servicio prolongadas; el artículo no responde a esos incidentes ni dice si la nueva arquitectura podría evitar situaciones similares. Celenza anuncia al final que la siguiente entrega de la serie detallará la arquitectura futura y los antecedentes de esta reforma.
Fuentes: blog de ingeniería de GitHub, CocoLoop; los datos oficiales de GitHub se usaron para verificar los criterios de conteo mensual de commits, pushes y ejecuciones de Actions.