The bridge to agent-scale Git infrastructure

Over the past year, as Git traffic on GitHub surged exponentially, the vast majority of repositories began residing in two locations simultaneously: GitHub's own data centers and Azure. The remaining repositories, which represented the busiest ones, were held back by a mere 25ms round trip latency. In a previous blog post, the company unveiled the two guiding principles behind their upcoming storage architecture: minimize coordination and decouple storage from compute. This article will focus on the transitional bridge from the old design to the new one.

The shift in timing and implementation was motivated by the agentic growth of traffic, the capacity limitations of data centers in the surrounding region, and physical supply chain constraints. At the onset of the migration, the remaining capacity offered sufficient time for a safe transition, but not a slow one. Although the new architectural approaches for scaling Git on cloud infrastructure had been prototyped, merging the storage architecture and hosting platform simultaneously was deemed too risky given the scale and criticality of the service.

Consequently, the work needed to be executed in a carefully sequenced manner: data migration first, followed by architecture evolution once the data arrived.

Git operations are classified as a Tier 0 service, which means they form the core functionality of GitHub and nearly every other aspect of the platform relies on repository data. As such, all data, services, and dependencies needed to be transferred to Azure before any architectural changes could be implemented.

The first copy of a repository arrived in Azure's Central US region in August 2025. By the present day, approximately half of Git traffic is served by Azure, with most repositories boasting two of their five replicas stationed in Azure. Until the final replica completes its relocation, the rest of the traffic continues to flow to the original data centers. To minimize read latency, Spokes employs preferential routing, directing traffic to replicas located in the same region and availability zone as the request.

During the migration, traffic naturally follows the data. Each repository possesses five replicas to ensure durability, availability, and scalability. By routing traffic to replicas within the same region and availability zone, read latency is minimized. As replicas migrate to Azure, the proportion of traffic that can be served from Azure increases with each successful move, ultimately leading to the cessation of requests being received by the original region.

Every repository undergoes this process: none will be left behind. In our current architecture, repositories hosted across multiple regions have a reduced write throughput ceiling. Spokes' quorum necessitates a majority to approve a write, waiting for every healthy replica's response (up to a timeout) before proceeding. Consequently, slow replicas hinder the entire write process, setting the latency and throughput ceiling.

By relocating replicas to the target Azure region, which is approximately 1,000 miles away, network round trips increase to 25ms, and a write requires multiple round trips. Once a repository reaches its write throughput ceiling, it cannot accommodate additional writes without falling further behind with every push.

To address this issue, the first principle, minimizing coordination, is applied. Specifically, the scope of the quorum is narrowed from the entire repository to individual references. In most cases, updates to different references don't depend on one another and can be applied independently. By changing the quorum to focus on individual references, a repository-wide lock for the entire reference update, including round trips, is eliminated.

As a result, writes no longer contend with one another, allowing them to be processed simultaneously without waiting on each other.

This adjustment results in a significant increase in write throughput, with internal testing demonstrating three to four times higher throughput at lower latency. Moreover, by decoupling storage from compute, reads and writes can now be independently scaled. For instance, reads can benefit from a more robust in-memory cache than previously provided, while compaction can be managed separately.

This separation enables each component to be configured optimally, ultimately improving the overall performance of the Git infrastructure.