How teams scaled Azure Blob Storage: 2 real case studies
2 of the 73 engineering write-ups in our database mention Azure Blob Storage in their stack. They come from 1 company (GitHub) and were published in 2026. Techniques that show up most often alongside Azure Blob Storage: read replicas (2). It's often paired with Git (2) and Spokes (2). 2 of the 2 state concrete scale numbers, for example "99.99999% of repositories copied to Azure" (GitHub). Each card below links to our short summary and the original post.
The bridge to agent-scale Git infrastructure
GitHub has copied 99.99999% of its Git repositories to Azure, where most now keep two of their five replicas and Azure serves about half of Git traffic. The busiest remaining repositories were blocked by a ~25ms cross-region round trip, because Spokes held a repository-wide lock for each write while waiting on the slowest healthy replica. Scoping the quorum to individual Git references lets writes to different branches proceed in parallel (3-4x higher throughput in internal testing), and a virtual write replica that streams writes into Azure Blob Storage lets stateless read replicas scale out on demand.
Building Git infrastructure for agent-scale development
GitHub explains why agent workloads strain Spokes, which keeps five durable copies of each repo on fileserver disks, so every added read replica slows writes. The new design coordinates only the ref update, moves compaction and GC to separate workers, and separates storage from compute: Azure Blob Storage holds the authoritative data while lightweight caching workers serve reads.