Generated by Codex with GPT 5.6 Sol High

GitHub’s hardest repositories exposed a subtle distributed-systems bottleneck: a quorum can require only a majority to commit and still be throttled by every healthy replica. GitHub’s existing storage layer waited for all healthy replicas before releasing a repository-wide write lock. Once replicas were split between its data centers and Azure, a roughly 25-millisecond cross-region round trip sat inside every serialized write. The design remained correct, but its coordination scope made the busiest repositories impossible to migrate without collapsing their throughput.

The official GitHub Engineering post, “The bridge to agent-scale Git infrastructure,” explains the intermediate architecture GitHub built while moving its repository fleet to Azure. The company has copied 99.99999% of repositories, placed two of the usual five replicas for most repositories in Azure, and shifted about half of Git traffic there. The remaining sliver includes some of the platform’s busiest repositories—the ones least able to absorb extra coordination latency as agent-driven Git traffic grows.

Serialize references, not repositories

The key insight comes from Git’s consistency model. Clients need a strict ordering for updates to the same reference, such as a branch or tag: after GitHub accepts an update, a client must not later observe an older value. But writes to unrelated references usually do not depend on one another. A push to one agent’s branch does not need to wait behind a push to another branch merely because both belong to the same repository.

GitHub is therefore shrinking the quorum’s serialization boundary from the entire repository to each individual reference. Under the old design, the repository-wide lock turned concurrent writes into one queue. Every write waited for the slowest healthy replica, held the lock across multiple network round trips, and delayed all later writes. As load rose, the queue lengthened until timeouts compounded the problem.

Per-reference serialization preserves ordering where it matters while allowing independent branch updates to remain in flight together. Each individual write still pays the cross-region latency, but that latency no longer sets a single throughput ceiling for the whole repository. In realistic internal tests, GitHub measured three to four times the write throughput, with lower latency, for updates to different references.

This is a useful example of reducing coordination without weakening consistency. The optimization does not make consensus faster or pretend the network is local. It asks a narrower question: which operations actually require a shared order? Concurrency appears once the system stops forcing unrelated state transitions through the same lock.

Make durable storage a quorum member

The second change separates read capacity from the replicas responsible for writes. GitHub says repositories commonly receive between 100 and 1,000 reads for every write, yet its current replicas serve both workloads. Reads, writes, and compaction therefore compete for the same CPU and memory, even though each benefits from a different configuration.

GitHub’s bridge to a disaggregated design is a “virtual write replica.” This ephemeral compute node joins the write quorum, streams accepted changes into Azure Blob Storage, and serves no reads. Because it participates in the quorum, GitHub does not acknowledge a write until that write is durable in object storage. The node also combines transactions on unrelated references into fewer network operations, letting a busy repository amortize one object-storage round trip across concurrent writes.

Once object storage is a durable source of truth, GitHub can start virtual read replicas on demand. A read replica warms its cache from Blob Storage, reconciles local state in the background, and takes traffic without joining the write quorum. Read compute can then scale independently, use more memory for caching, and disappear when it is no longer needed. In GitHub’s distributed load tests, the test harness reached its own capacity limit before it found a ceiling for these virtual readers.

The design is not finished. Background reconciliation is suitable for only some read paths; broader coverage will require fetching changed references and objects inline. The existing quorum also remains the limiting factor for future write growth. Git objects simplify the next step because they are immutable and content-addressed, so replicas do not need consensus to store them. The smaller but harder problem is ordering mutable references and deciding how durable reference state, compaction, and garbage collection should work around that ordering layer.

Migration architecture is real architecture

GitHub could have tried to replace its storage protocol while moving a billion repositories to a different hosting environment. Instead, it separated the risks: copy data first, preserve the proven service boundary, then change coordination and storage incrementally underneath live traffic. That sequencing matters because Git operations are a Tier 0 dependency for nearly everything else on GitHub, and its Spokes layer handles well over 100 billion operations per day in addition to routing, placement, repair, and rebalancing.

The broader lesson is that transitional systems deserve first-class design. Per-reference quorums and virtual replicas are not disposable migration glue; each removes a specific bottleneck while moving the running platform toward its intended end state. The most robust path to a radically different architecture is often a series of intermediate designs that improve production immediately, preserve a rollback surface, and make the next change easier.

Agentic coding is the pressure behind this work, but the engineering principle is older and more general. When growth turns latency into a throughput limit, the first response should not automatically be faster hardware or weaker guarantees. Often the decisive move is to find the smallest state that truly needs coordination, then let everything else scale around it.