How GitHub Rebuilt Git Writes for Agent-Scale Traffic

This post from GitHub reproduces the engineering article The bridge to agent-scale Git infrastructure, which is also in Intel as its blog-post record. GitHub says agent-driven growth and a power ceiling at its own data centers pushed it to put copies of repositories in Azure; today most repositories keep two of their five replicas there and Azure serves about half of Git traffic. A copy of 99.99999% of repositories has made the move. The holdouts are some of the busiest, and the obstacle is a round trip of about 25ms to an Azure region roughly 1,000 miles away.

The reason a few milliseconds matter is how Spokes, GitHub's replication layer, commits a write. It needs only a majority, but it waits for every healthy replica to answer, up to a timeout, and each write holds a lock on the whole repository until it commits. So the slowest replica sets both the latency of each write and how many writes the repository can absorb, and a write takes several round trips. A repository already near that ceiling would fall further behind with every push once one replica sat across the region boundary.

The fix rests on how Git defines consistency: the guarantee that no client sees an older value after an update is accepted applies to each reference, such as a branch, on its own. GitHub is moving the quorum's scope from the repository to individual references, so only writes to the same reference wait for each other. Agents and developers pushing to their own branches no longer queue behind one another; each write still pays the cross-region delay, but many can be in flight at once. GitHub says the ceiling rises roughly with the number of references being written concurrently, and that internal tests with realistic traffic showed 3 to 4 times higher throughput at lower latency for writes to different references.

The same change makes a second step affordable. GitHub is adding Azure Blob Storage to the quorum as a virtual replica, an ephemeral node that streams writes to object storage and serves no reads, so a write is acknowledged only once it is durable there; it also batches writes to separate references into shared network calls. Read replicas can then be started on demand, warming from object storage without joining the quorum, which matters because most repositories see 100 to 1,000 reads per write. These replicas reconcile with storage in the background, so they suit only some read workloads for now, and GitHub says the quorum itself remains the limit on write throughput, which a final post in the series is due to address.