Por Canuto  

GitHub prepara una nueva arquitectura de almacenamiento tras un fuerte aumento del tráfico y los commits asociados al uso de agentes de IA. Las primeras pruebas internas apuntan a una mejora de 35 veces en escritura, aunque la empresa no ha anunciado un calendario de migración.
***

  • El tráfico mensual de GitHub pasó de 218.200 millones de eventos en septiembre de 2025 a 473.300 millones en agosto de 2026.
  • La propuesta reemplaza el quórum de réplicas de Spokes por escrituras en Azure Blob Storage y canales separados para lecturas.
  • GitHub no precisó cuándo completará el cambio, que busca mantener los flujos de trabajo y controles actuales.

Sumario: GitHub rediseña su almacenamiento para responder al auge de los agentes de IA, reducir cuellos de botella y sostener el crecimiento de la actividad en sus repositorios.

El crecimiento pone a prueba la infraestructura

GitHub está reconstruyendo su arquitectura de almacenamiento Git ante el aumento de actividad que la compañía atribuye, en parte, al uso de agentes de inteligencia artificial para programar. Las pruebas iniciales de la nueva propuesta muestran una mejora de 35 veces en escritura, según resultados internos citados por The Register. Esa cifra todavía no equivale a una mejora desplegada para todos los usuarios: la empresa no ofreció un calendario para completar la migración.

El cambio responde a una aceleración marcada en el volumen de operaciones de la plataforma. Entre septiembre de 2025 y agosto de 2026, el tráfico mensual de GitHub pasó de 218.200 millones a 473.300 millones de eventos, más del doble en menos de un año. En septiembre, los commits llegaron a 7.380 millones, cinco veces el total registrado en el mismo mes de 2025, de acuerdo con los datos incluidos en el reporte.

Ese crecimiento también ha elevado la presión sobre la disponibilidad del servicio. El Informe de Disponibilidad de GitHub contabilizó diez incidentes que degradaron el rendimiento durante abril y otros nueve en mayo; la información disponible no atribuye cada episodio a una causa específica. El contexto, sin embargo, muestra por qué la compañía busca una infraestructura capaz de manejar lecturas y escrituras concurrentes de forma sostenida, en vez de depender de un diseño pensado para cargas menores.

Brian Celenza, ingeniero principal de software de GitHub, describió el desafío como el soporte simultáneo a grandes equipos de ingeniería, pipelines de integración continua ocupados y flotas crecientes de agentes. Esa combinación importa porque los agentes pueden generar cambios y operaciones de repositorio con una intensidad distinta a la de un equipo humano que trabaja de forma secuencial. Celenza señaló que pocos repositorios enfrentan actualmente una escala comparable.

Qué cambiará con el fin de Spokes

La arquitectura que GitHub quiere sustituir se conoce como Spokes y replica repositorios completos en varios discos locales. Para confirmar una escritura, el sistema utiliza un protocolo de tres fases y espera el quórum requerido de réplicas. El diseño prioriza la fiabilidad, pero impone una limitación: cada envío de cambios debe esperar a que respondan las réplicas necesarias, por lo que la más lenta puede convertirse en el cuello de botella.

La alternativa plantea escribir cada commit una sola vez en Azure Blob Storage, el servicio de almacenamiento de objetos de Microsoft. Allí, el propio servicio administra la replicación y la redundancia, en lugar de exigir que GitHub coordine múltiples copias locales antes de confirmar cada operación. Según la descripción de Celenza, ese cambio elimina el paso del quórum que condiciona hoy la velocidad de escritura, aunque no significa que el almacenamiento deje de gestionar copias redundantes.

El rediseño también separa las solicitudes de lectura de las operaciones de escritura y las asigna a trabajadores de cómputo ligeros. La coordinación entre ambos canales quedaría concentrada en los punteros de las ramas de referencia, que indican a qué commit apunta cada rama. En términos prácticos, GitHub busca que consultar un repositorio no tenga que competir del mismo modo con la incorporación de cambios, una distinción relevante cuando muchas tareas automatizadas interactúan con el código a la vez.

Las tareas de mantenimiento también saldrían del camino de servicio. Procesos como la compactación y la recolección de basura pasarían a ejecutarse en segundo plano, en lugar de competir directamente con las operaciones que hacen los usuarios. GitHub presenta el plan como un cambio interno que debería evitar alterar los flujos de trabajo de desarrollo, las revisiones de código y los controles de seguridad; por ahora, la empresa no comunicó cuándo empezará o terminará el despliegue.

Una industria que adapta Git a los agentes

El giro de GitHub forma parte de una conversación más amplia sobre si las prácticas tradicionales de Git se ajustan a las cargas de trabajo basadas en agentes. El ex director ejecutivo de GitHub, Thomas Dohmke, lanzó Entire, un servicio de alojamiento Git que desvía actividad de agentes hacia repositorios espejo. Con ese esquema, los repositorios principales de un cliente pueden concentrarse en el tráfico habitual de desarrollo, mientras los espejos absorben parte de las operaciones automatizadas.

Cursor también modificó su capa de almacenamiento para mejorar el rendimiento de su servicio de soporte a agentes. Según el reporte, la empresa, descrita allí como subsidiaria de SpaceX, descartó el protocolo de confirmación en tres fases usado por Spokes y optó por subir los cambios a un registro de escritura anticipada, conocido como WAL, en almacenamiento de objetos. El sistema registra los cambios como objetos inmutables y mantiene en caché al menos una copia en discos de estado sólido de alta velocidad.

Las experiencias de Entire y Cursor no demuestran que exista una solución única para todos los repositorios, pero sí ilustran dos respuestas al mismo problema: separar o redirigir parte del trabajo generado por agentes para aliviar la carga de los sistemas centrales. GitHub, en cambio, propone rehacer su propia capa de almacenamiento y conservar el funcionamiento visible para desarrolladores y equipos. La diferencia está en el alcance: su objetivo es cambiar la infraestructura bajo el servicio, sin pedir a los usuarios que adopten otro flujo.

Sam Lambert, director ejecutivo de PlanetScale, sostuvo en un mensaje en X que ha visto empresas dedicar tres meses a preparar eventos capaces de aumentar el tráfico entre 10% y 20%, una magnitud que consideró pequeña frente a la presión que enfrenta GitHub. Su comentario sirve como referencia sobre la escala del reto, pero no constituye una medición independiente de la carga de la plataforma. El resultado práctico dependerá de cómo se comporte la nueva arquitectura cuando pase de las pruebas internas a las operaciones reales.

Por ahora, la mejora de 35 veces es una promesa respaldada por pruebas iniciales internas, no una garantía de que todos los usuarios percibirán repositorios 35 veces más rápidos. La prueba central será si el nuevo diseño reduce los retrasos y sostiene el crecimiento sin comprometer la fiabilidad, al tiempo que preserva las revisiones, la seguridad y las rutinas existentes. Sin un calendario público, queda pendiente saber cuándo GitHub pondrá a prueba el cambio a escala completa.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados