SYSTEM Cited by 2 sources

Spokes¶

Spokes is GitHub's Git storage system that has backed the platform for years: every repository is stored as a full copy on the local disks of several fileservers — five by default. Those fast local disks let Git operations read native repository data with low latency, and the extra copies provide redundancy while spreading reads across fileservers. Spokes backs roughly a billion repositories today. (Source: sources/2026-10-06-github-building-git-infrastructure-for-agent-scale-development)

Consistency protocol¶

When a push updates a reference, Spokes uses a three-phase commit protocol with a quorum to ensure that CI, the web UI, and API clients all see a consistent repository state. This is Git-visible strong consistency on ref updates: a push isn't acknowledged until a quorum of replicas agrees.

The architectural ceiling (why GitHub is replacing it)¶

The defining property — and limitation — of Spokes is that the same mechanism provides both durability and scale. The on-disk copies ARE the source of truth, so:

Adding read capacity means adding another durable replica. There is no way to add read throughput without adding a copy that also participates in writes.
Every replica participates in every write, so "a push is only as fast as the slowest replica in its set." Adding read replicas therefore slows writes — the coupling that compute–storage separation is meant to break.
Losing a replica reduces read capacity; losing quorum stops writes entirely.

For most repositories this tradeoff works well. At the highest activity levels (agent fleets + busy CI on a single repo), it becomes a hard ceiling. The replacement architecture separates durability (→ Azure Blob Storage) from serving (→ lightweight stateless cache workers), and runs compaction / GC on separate workers against durable storage instead of on the live-serving fileservers.

The bridge: narrowing the quorum from repo to reference (2026-10)¶

The 2026-10-21 follow-up describes the immediate bridge step that evolves Spokes in place while the data has already moved to Azure. Two changes matter.

Quorum scope: repository → individual reference¶

The original Spokes quorum "only needs a majority to commit a write, but it waits for every healthy replica to respond (up to a timeout) before moving on" — so slow replicas delay every write rather than falling behind. Combined with a repository-wide lock held until commit, this makes the slowest healthy replica set both the latency and the throughput ceiling of the entire repo. The lock turns the quorum into "a single, unordered request queue with one write in flight at a time" — textbook head-of-line blocking, where queue depth and per-write wait grow with the write rate. (Source: sources/2026-10-21-github-the-bridge-to-agent-scale-git-infrastructure)

The fix applies GitHub's "minimize coordination" tenet: Git's consistency requirements apply per reference (once a ref update is accepted, no client may see an older value — true for fast-forward, force-push, or delete), but updates to different refs are usually independent. So Spokes changes the quorum's scope from the whole repository to the individual reference. Only writes that contend on a shared ref wait for each other; writes to different refs (agents/devs on their own branches) run concurrently, each still paying the cross-region latency but no longer queued behind one another. This raises the write ceiling "roughly in proportion to how many references are being written at once"; internal testing with realistic traffic saw 3–4× higher throughput at lower latency, and it gets the last ~0.00001% (busiest) repos into Azure despite the ~25 ms cross-region round trip.

Virtual replicas: object storage as a quorum member¶

The first step toward compute–storage separation is making Azure Blob Storage a special quorum member — a virtual replica. The compute representing it is Spokes' first fully ephemeral node:

Virtual write replica — bridges to object storage, streams incoming writes, serves no reads. Because it is in the quorum, a write isn't acknowledged until it is durable in object storage. It also coalesces transactions on disjoint references into a single set of network I/Os to the blob store, so a busy repo "pays for one round trip across many concurrent writes instead of one per write." For now it also runs compaction, and read replicas inherit the compacted state. Per-reference serialization keeps the extra object-storage hop off the throughput critical path.
Virtual read replicas — spun up on demand, warm their cache from Azure Blob Storage and take read traffic without joining the quorum, using object storage as the source of truth and reconciling local state in the background. This scales reads independently of writes (repos are 100–1,000× read-skewed). In load testing the current architecture "routinely found ceilings"; against virtual read replicas the harness "hit its own limits first." (A caching proxy tier over a durable store.)

Acknowledged limits of the bridge: background reconciliation fits some read workloads but not all (in-line reconciliation is deferred), and the quorum remains the bounding factor for pushing write throughput further.

Spokes is more than a quorum¶

The 2026-10-21 post emphasizes that over the years Spokes grew well beyond a quorum coordinator. It is also:

an intelligent routing and load-balancing layer — including preferential routing that sends each request to a replica in the same region/AZ (so during migration "traffic follows the data" as replicas move to Azure);
a unified API internal clients use to access and transact repository data at well over 100 billion operations per day;
a collection of background systems called "sweepers" that handle repository placement, repair, and rebalancing between storage nodes.

Most of this applies equally to the new architecture. The part that must change is the commit protocol: GitHub concedes "the commit protocol that has taken GitHub to a billion repositories won't take it to the next billion." Because Git objects are immutable and content-addressed, they can be stored without anyone agreeing on them; what's left to order is small, and the open problem is ordering it fast without moving the bottleneck — leaving "a (small) consensus group somewhere in the stack" in the end state.

Stub page¶

Covered here at the depth load-bearing for the agent-scale-infrastructure source: the 5-copy local-disk model, the three-phase-commit quorum on ref updates, and the durability-equals-scale coupling that motivates the rebuild. Deeper Spokes internals (placement, rebalancing, the original "Stretching Spokes" work) are not yet ingested.

Seen in¶

sources/2026-10-06-github-building-git-infrastructure-for-agent-scale-development — Spokes described as the current Git storage architecture: full repo copies on ~5 fileservers, three-phase-commit quorum ref updates, and the durability/scale coupling that caps the busiest repos. Being replaced by a compute–storage-separated design.
sources/2026-10-21-github-the-bridge-to-agent-scale-git-infrastructure — primary subject: the bridge step. Quorum scope narrowed from repository to individual reference (waits for every healthy replica + repo-wide lock → one-in-flight HOL queue → 3–4× write throughput once per-ref); object storage joins the quorum as a virtual write replica (ephemeral, write-only, durability-gating, I/O-coalescing, runs compaction); on-demand virtual read replicas scale reads off the quorum. Also: Spokes as routing/load-balancer with preferential routing, a unified API at >100 B ops/day, and "sweeper" background systems for placement/repair/rebalance.

systems/github — the SaaS layer Spokes stores repositories for.
systems/git — the ref-update + object semantics the quorum protocol protects; per-reference consistency is what lets the quorum scope shrink.
systems/azure-blob-storage — the durable layer the new architecture moves authoritative data to; becomes a quorum member via the virtual replica.
concepts/compute-storage-separation — the property Spokes lacks and the rebuild adds.
concepts/strong-consistency — what the three-phase-commit quorum guarantees on ref updates, now scoped per reference.
concepts/head-of-line-blocking — the repo-wide-lock pathology (one write in flight) that per-reference serialization removes.
concepts/network-round-trip-cost — the ~25 ms cross-region RTT that makes per-write serialization untenable for the busiest repos.
concepts/hot-key — the single-ref merge contention Spokes funnels onto one point (the one case per-ref serialization still has to serialize).