📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
Cuando un agente de código hace push, nadie pregunta si el sistema detrás aguanta. Uno asume que sí, po: GitHub lleva años operando y ya está. Pero hace pocos días publicaron los internos de su nueva arquitectura de almacenamiento Git y salió un número de pura ambición: en pruebas internas sostienen 7.200 pushes por segundo en un solo repositorio, con 5.000 agentes concurrentes pegándole al mismo lugar. Para calibrar: hoy los repos más movidos del sitio llegan a decenas de writes por segundo, en ráfagas cortas. La meta quedó a dos órdenes de magnitud de distancia.
Una observación sostiene todo
Lo elegante es que la pieza central ya existía: en Git casi nada necesita consenso. Los objetos son inmutables y los nombra el hash de su contenido; dos escritores pueden guardar el mismo objeto a la vez sin coordinarse y no pasa nada. Lo único de un push que requiere acuerdo es actualizar una referencia: mover un puntero de pocos bytes que dice dónde apunta la rama. Toda la nueva arquitectura explota esa asimetría. Y la presión es real: en uno de los repos más activos, el tráfico creció de 44 a 181 millones de peticiones diarias entre marzo y mayo de este año, un 4x que atribuyen directamente a los agentes.
Qué cambió por debajo
Para el usuario no cambia nada: sigues haciendo push, fetch y branch igual. Por debajo quedó un sistema de piezas desacopladas. Las réplicas virtuales son cómputo desechable: su disco local es solo caché, reconstruible en cualquier momento, y si una muere, las demás siguen sirviendo y una nueva llena su caché conforme llega tráfico. Los packs de objetos viven en Azure Blob Storage, donde casi todo se escribe una vez y jamás se toca de nuevo. Y las referencias se ordenan en un servicio aparte, Ref-CAS, un log replicado que hace compare-and-swap por quórum: cada transacción bloquea solo las referencias que toca. Como cada agente suele empujar a su propia rama, la mayoría no pelea por nada; cuando dos tocan la misma referencia, una gana y la otra reprocesa, y Git resuelve como siempre.
Agradecí que contaran los intentos fallidos: su primer prototipo mantenía un write-ahead log de referencias en un solo blob y quedó en los pocos cientos de writes por segundo. El segundo trozó las referencias en segmentos por hash, subió la escritura, pero envenenó la lectura, que es lo que de verdad genera el fan-out (CI, despliegues y otros agentes bajando cada commit). De esas dos lecciones salió el servicio dedicado, con decenas de miles de operaciones de referencia por segundo, y el compaction y garbage collection se corren en nodos aparte con leases por shard, así las réplicas no gastan CPU ni memoria en mantener el repo ordenado. Diseño de sistemas de libro, sin magia.
Lo que opino
El detalle que más me gusta es honesto y raro de ver: los agentes esperan cada push antes de seguir, así que la métrica que importa es la latencia de commit bajo carga, no el throughput bruto. Y del «Git sigue siendo Git» me fío con letra chica: las lecturas vienen con desfase acotado respecto al último write. Para un agente que consulta por su propia rama está perfecto; para una revisión humana crítica, el modelo mental del repo puede irle al tranco detrás. Es un trade-off razonable, pero conviene cacharlo.
La arquitectura está en preview privado y la expansión llega a comienzos del próximo año. Después vienen clones livianos, un API de commit atómico para cambios multi-archivo y agentes que trabajan sin siquiera clonar el repositorio. Mi pronóstico: en dos años nadie recordará que un repo necesitaba atención especial cuando una flota de agentes se le subía encima. Y una vez que el límite deja de ser la infraestructura, vuelve a ser el que siempre gana: decidir qué vale la pena escribir. Ese no lo resuelve ningún log replicado.
Fuente de inspiración: Inside GitHub’s new Git storage architecture
