Introducción
Git fue diseñado para la colaboración humana: unos pocos desarrolladores, merges ocasionales y una coordinación esencialmente manual. Desde 2025, el auge de los agentes de IA ha transformado radicalmente su régimen de uso. GitHub registró 473.300 millones de eventos Git en un solo mes, agosto de 2026, un volumen que se duplicó en menos de un año. Ante esta carga sin precedentes, una infraestructura con más de una década de antigüedad comenzó a mostrar sus límites. La respuesta se llama Rubicon.
Spokes: el modelo anterior
Durante años, GitHub se apoyó en una arquitectura llamada Spokes: copias replicadas de cada repositorio distribuidas en varios servidores, con un mecanismo de consenso para mantener la coherencia. Este diseño sirvió bien a millones de equipos, pero tenía un techo estructural: unos pocos cientos de operaciones de escritura por segundo como máximo en un repositorio dado. Las escrituras se bloqueaban entre sí, y la compactación, el proceso de mantenimiento que reorganiza los objetos Git en segundo plano, consumía recursos de los servidores de producción.
El punto de quiebre llegó entre marzo y mayo de 2026: un repositorio especialmente activo vio cómo sus solicitudes diarias se disparaban de 44 millones a 181 millones en apenas dos meses. Cuatro veces más carga sobre un sistema dimensionado para absorber mucho menos.
La arquitectura Rubicon en tres capas
Presentado en GitHub Universe en noviembre de 2026, el Proyecto Rubicon reorganiza fundamentalmente el almacenamiento Git en torno a tres componentes independientes que escalan por separado.
Los objetos Git, commits, árboles, blobs, son inmutables por naturaleza. Su contenido no cambia una vez escrito, lo que permite almacenarlos en Azure Blob Storage sin ningún tipo de coordinación. Un blob es un blob, identificado por su hash y recuperable desde cualquier nodo sin necesidad de sincronización.
Las referencias (ramas, etiquetas) son mutables y exigen coherencia estricta. Aquí entra en juego Ref-CAS, un servicio de registro replicado basado en un mecanismo de compare-and-swap con quórum mayoritario. Cada actualización de referencia pasa por una votación entre réplicas antes de validarse. Al estar desacoplado del almacenamiento de objetos, Ref-CAS puede procesar decenas de miles de operaciones por segundo con independencia del volumen de datos.
La capa de cómputo, las réplicas virtuales, pasa a ser sin estado persistente: nodos ligeros que mantienen una caché local, atienden solicitudes de lectura y delegan la escritura en la infraestructura central. Si un nodo cae, no se pierde nada.
El resultado de esta separación: 7.200 pushes por segundo hacia un único repositorio con 5.000 agentes concurrentes, es decir, una mejora de 35x respecto al sistema anterior en operaciones de escritura.
Reconstruir en pleno vuelo
Lo que hace notable esta migración desde el punto de vista de la ingeniería es que se ejecutó sin ninguna interrupción de servicio, sobre una plataforma que aloja cientos de millones de repositorios. El 99,99999 % de los repositorios de GitHub ya había sido migrado a Azure en un proyecto anterior. Rubicon se construyó por debajo, reemplazando progresivamente las capas inferiores mientras el sistema permanecía operativo.
Este enfoque, modificar los cimientos sin cortar el suministro, es uno de los retos más complejos de la ingeniería de software en producción. Exige una disciplina estricta en materia de retrocompatibilidad, observabilidad y despliegue progresivo.
Lo que los equipos DevOps deben tener en cuenta
Los principios que guían Rubicon, simplificar las primitivas, desacoplar el almacenamiento del cómputo, minimizar la coordinación, no son exclusivos de GitHub. Reflejan los grandes patrones de los sistemas distribuidos modernos aplicados a un problema que durante mucho tiempo se consideró resuelto.
Para los equipos que gestionan forjas internas o pipelines de CI/CD de alta intensidad, la lección es doble: el desacoplamiento entre estados mutables e inmutables no es un lujo reservado a los grandes hiperescaladores, y los monolitos de almacenamiento que funcionan bien hoy pueden convertirse en los próximos cuellos de botella a medida que los agentes de IA se integran en las cadenas de entrega de software.
Rubicon se encuentra actualmente en versión preliminar privada limitada. Un despliegue más amplio está previsto para principios de 2027.