GitHub is facing unprecedented growth in operational intensity on Git, driven by the proliferation of AI software and AI agents that generate intensive and continuous streams of modifications and updates. To address physical limitations on power capacity in traditional data centers and supply chains, the company unveiled an architectural plan that has so far relocated copies of 99.99999% of its repositories to reside jointly between its private data centers and Microsoft Azure.
The latency bottleneck and full repository lock
GitHub explained that the most heavily used and modified repositories on the platform—which represent the minuscule remaining percentage (0.00001%)—were facing a technical barrier in the form of network latency. When data is moved to the Central US Azure region, located about a thousand miles away from the platform's data centers, each network connection adds a latency of roughly 25 milliseconds in round-trip time.
In the legacy Spokes synchronization and consensus architecture, any new write operation required enforcing a repository-wide lock until replicas responded. Because of the repository-wide lock, the slowest network replica determined the response time and maximum throughput ceiling for the entire repository, causing bottlenecks in active repositories receiving frequent code pushes from developers and AI agents.
Per-reference consensus
To overcome this bottleneck, GitHub redesigned the consensus mechanism by applying its first architectural principle: "minimize coordination and eliminate unnecessary locking." Instead of locking the entire repository during an update, the scope of consensus and locking now applies exclusively to per-reference serialization, such as branches or tags.
Since most concurrent write operations executed by developers or AI agents target different branches, modifications no longer wait for each other in a single queue. Internal testing conducted by the company under realistic loads showed a 3x to 4x increase in write capacity with a noticeable decrease in latency.
Decoupling storage from compute and universalizing object storage
The second phase involves implementing the second architectural principle: "Decoupling storage from compute." Most Git repositories are characterized by read-heavy workloads compared to writes, with ratios ranging from 100 to 1,000 reads for every single write. In the legacy architecture, reads and writes competed for the same resources and memory.
To solve this, GitHub integrated Azure Blob Storage as a virtual member of the consensus council called the "Virtual Write Replica." This replica acts as a transient pipeline that aggregates transactions and streams modifications persistently to cloud storage. Once storage is confirmed, the platform can spin up an unlimited number of on-demand Virtual Read Replicas, which update their caches behind the scenes without impacting data write speed or synchronization.
What changes practically for the software development architecture?
This engineering shift at GitHub reflects how massive distributed systems are being redesigned to withstand the nature of automated AI-driven work, with the key practical impacts summarized as follows:
- Raising the throughput ceiling: Enabling AI agents and developers to perform intense concurrent pushes without locks on major repositories.
- Read scaling flexibility: The ability to scale read servers and allocate caching independently without heavy consensus procedures.
- Core system continuity: Upgrading the internal components of the Spokes system—which executes over 100 billion operations daily—without downtime or sacrificing data integrity.