GitHub rediseña el almacenamiento de Git: 5.000 agentes en un repositorio y 7.200 pushes por segundo

Git fue creado para personas. Un desarrollador hace un commit, envía un par de pushes al día, de vez en cuando entra en conflicto con un compañero, y todo eso supone una carga moderada para el servidor. Los agentes rompen este modelo: escriben código en paralelo, con frecuencia y sin pausas para el café. GitHub ha informado de una prueba que muestra hasta dónde está dispuesto a llevar este cambio.

Lo que anunció GitHub

Según la cuenta oficial, durante una prueba interna la nueva arquitectura de almacenamiento de Git de GitHub soportó 5.000 agentes trabajando simultáneamente en un único repositorio. Estos generaron 7.200 pushes por segundo. Al mismo tiempo, el servicio siguió atendiendo solicitudes de lectura con una latencia baja y estable. La propia publicación no ofrece detalles, solo un enlace al artículo. Por tanto, todo lo que aparece a continuación sobre el diseño del sistema debe entenderse como un marco para la reflexión, no como una reconstrucción de la arquitectura.

Que problema resuelve

Imagine una intersección concurrida con un semáforo diseñado para cinco coches por minuto. Mientras conducen personas, todo funciona. Cuando aparecen 5.000 coches autónomos, comienza el atasco. Con un repositorio ocurre algo parecido: cada push actualiza referencias y escribe objetos, y con una alta concurrencia las escrituras empiezan a interferir con las lecturas. Sin embargo, todos necesitan leer: las clonaciones, el CI, las revisiones y los agentes vecinos que descargan el código más reciente.

La cifra principal no son los 5.000 agentes, sino la combinación simultánea de dos condiciones: un alto volumen de escritura y una baja latencia de lectura. También es posible absorber picos de escritura degradando todo lo demás. Aquí se afirma que el rendimiento de lectura no se desplomó.

Por que esto importa ahora mismo

Los flujos de trabajo con agentes se están alejando rápidamente del modelo en el que un asistente ayuda a una persona. Cada vez es más habitual que una sola persona lance decenas de intentos paralelos para resolver una tarea, cada uno en su propia rama. Si la infraestructura no soporta esa carga, los equipos chocan con el almacenamiento, los límites y las colas, no con la calidad de los modelos.

Para los equipos de producto y los fundadores, esto es una señal: las plataformas de desarrollo se están reconstruyendo para un nuevo usuario que no es humano. Las herramientas que traten a un agente como un cliente convencional, con límites convencionales, pronto se convertirán en cuellos de botella.

Que hacer en la practica

Primero, calcule cuántos pushes por minuto genera realmente su sistema de agentes. Para la mayoría de los equipos serán unidades o decenas, no miles, por lo que el récord de GitHub todavía no les afecta.

Segundo, compruebe dónde está ahora su cuello de botella. Las causas habituales son los conflictos de fusión en un mismo archivo, un CI lento para cada commit y los límites de las API. El almacenamiento no suele ser la primera limitación.

Tercero, separe el trabajo de los agentes por ramas y zonas del código. Cinco mil agentes modificando el mismo archivo se ahogarán en conflictos independientemente de la velocidad del servidor.

Cuarto, observe cómo GitHub convierte esto en un producto, en qué planes lo ofrece y con qué límites. Por ahora, se trata de un anuncio sobre pruebas internas.

Limitaciones

La prueba es interna y no se ha revelado su metodología. No conocemos el tamaño del repositorio, el tamaño de los pushes, la proporción de cambios en conflicto ni qué significa “baja latencia” en milisegundos. Tampoco está claro cuándo estará disponible esta capacidad ni para quién. Por eso, la reacción correcta es tomarla como una señal sobre la dirección del desarrollo, pero no incorporar estas cifras a los planes hasta que existan mediciones independientes.

La conclusión es sencilla. Con los agentes, Git está pasando de ser una herramienta para personas a convertirse en un sistema de alta carga. GitHub afirma que se está preparando para ello. Los demás deberían pensar con antelación cómo se comportarán sus procesos cuando el número de pushes se multiplique por cien.