GitHub ha detallado Rubicon, una arquitectura de almacenamiento Git que separa los objetos inmutables de las referencias que necesitan consenso. En pruebas internas, la empresa afirma haber sostenido 5.000 agentes concurrentes y 7.200 pushes por segundo sobre un repositorio mientras mantenía baja la latencia de lectura.
Esas cifras proceden del artículo técnico de GitHub y de una carga diseñada para el futuro. El texto no dice que cualquier repositorio reciba hoy ese tráfico ni publica un benchmark reproducible fuera de GitHub.
El problema aparece después de cada push
Los repositorios más ocupados reciben hoy como máximo decenas de escrituras por segundo en ráfagas. GitHub espera que los agentes conviertan esas ráfagas en actividad sostenida. Cada escritura provoca lecturas adicionales: CI, despliegues y otros agentes descargan el nuevo estado.
En un repositorio observado por GitHub, las peticiones diarias pasaron de una media de 44 millones en marzo a 181 millones en mayo, cerca de cuatro veces más. Es un caso interno y no una tasa general para todos los proyectos.
Una escritura toca dos almacenes
- Una réplica virtual indexa el pack recibido y lo sube a Azure Blob Storage.
- Después confirma en Ref-CAS una transacción que añade el pack al manifiesto y actualiza las referencias.
- Un nodo de compactación combina packs en segundo plano sin quitar CPU a las réplicas que atienden tráfico.
Los objetos de Git se nombran por su contenido y no cambian. Pueden escribirse en paralelo sin ponerse de acuerdo. Las referencias —ramas y etiquetas— son pequeñas, pero varias escrituras pueden competir por actualizarlas. Ref-CAS usa compare-and-swap y un quórum para ordenar solo esas referencias.
Las réplicas locales son cachés reconstruibles
Spokes dirige cada solicitud a un grupo pequeño de réplicas virtuales. Su disco local no es la fuente duradera: sirve como caché y puede reconstruirse. Si una réplica desaparece, las demás continúan y el reemplazo recupera los packs necesarios a medida que llegan peticiones.
Una lectura empieza comparando la versión local de referencias con Ref-CAS. Si no ha cambiado, no necesita transferir la lista completa. Si va retrasada, recibe referencias actuales y punteros a los packs que debe traer desde Blob Storage.
Qué aporta el diseño a equipos que coordinan agentes
- Reduce la coordinación global cuando los agentes trabajan en ramas distintas.
- Separa la compactación y la recolección de basura de la ruta que atiende pushes y fetches.
- Permite aumentar réplicas para lectura y escritura sin mover el estado duradero.
- Mantiene la interfaz Git: push, fetch, ramas y protecciones siguen siendo los conceptos visibles.
La arquitectura no resuelve conflictos lógicos entre agentes, revisiones defectuosas ni gasto descontrolado de CI. Acelera el plano de almacenamiento; las reglas de ramas, pruebas y coordinación continúan en capas superiores.
Pando de OpenAI también persigue Git a escala de agentes, pero no es el mismo sistema: Rubicon pertenece a la infraestructura de GitHub y conserva la experiencia pública de la plataforma.
Lo siguiente todavía es una hoja de ruta
GitHub plantea lecturas de objetos individuales, packs por tipo, réplicas parciales, vistas materializadas, réplicas globales y escalado a cero. El texto las presenta como áreas futuras, no como capacidades disponibles para contratar o configurar hoy.
Transparencia: noticia elaborada con asistencia de IA a partir del artículo técnico de GitHub. Texploto no reprodujo la carga ni inspeccionó la infraestructura.
