O GitHub transferiu cópias de 99,99999% de seus repositórios para o Azure, mantendo também cópias em seus próprios data centers. Os repositórios restantes estão entre os mais movimentados da plataforma, e a latência de rede entre regiões tem dificultado a migração. A empresa afirma que mudar a forma como coordena as gravações ajudará a transferi-los e dará suporte à transição para uma infraestrutura projetada para o tráfego crescente de desenvolvedores e agentes de IA.
A migração começou com a chegada de uma cópia de um repositório à região Central US do Azure, em agosto de 2025. A maioria dos repositórios agora tem duas de suas cinco réplicas no Azure, que atende a cerca de metade do tráfego do Git. O GitHub optou por mover os dados antes de alterar sua arquitetura de armazenamento, citando a importância das operações do Git e os riscos de mudar ao mesmo tempo a plataforma de hospedagem e a arquitetura.
No projeto atual, um quórum de gravação aguarda a resposta de todas as réplicas em funcionamento, embora uma maioria seja suficiente para confirmar uma gravação. Como um bloqueio de todo o repositório permanece ativo até a conclusão da gravação, a réplica mais lenta pode limitar tanto a latência quanto a capacidade de processamento. Como as réplicas no Azure ficam a cerca de 1.000 milhas dos data centers do GitHub, uma ida e volta pela rede leva aproximadamente 25 milissegundos, e as gravações exigem várias dessas viagens.
A mudança proposta pelo GitHub é coordenar as gravações por referência, em vez de coordená-las em todo o repositório. As referências incluem ponteiros de branches, e a empresa afirma que atualizações em referências diferentes geralmente não dependem umas das outras. Com a nova abordagem, as gravações na mesma referência continuam aguardando umas pelas outras, enquanto as gravações em referências distintas podem ocorrer simultaneamente. Em testes internos com tráfego realista, o GitHub relata uma capacidade de processamento 3–4 vezes maior para gravações em referências diferentes, com latência menor.
A mudança também possibilita uma estratégia independente de ampliação para as leituras. O GitHub afirma que os repositórios normalmente recebem entre 100 e 1.000 leituras para cada gravação, mas atualmente os dois tipos de tráfego usam as mesmas réplicas e competem por recursos. O próximo passo é incluir o Azure Blob Storage no quórum de gravação por meio de uma “réplica virtual”. Esse nó efêmero transmite as gravações recebidas para o armazenamento de objetos, e uma gravação só é confirmada depois de estar armazenada de forma durável.
A réplica virtual de gravação não atende a leituras. Em vez disso, o GitHub pode criar réplicas virtuais de leitura sob demanda, aquecendo seus caches a partir do Blob Storage e atendendo ao tráfego de leitura sem que elas participem do quórum. Em testes internos de carga, o GitHub afirma que seu sistema de testes atingiu os próprios limites antes de encontrar um limite para essas réplicas. A empresa observa que a reconciliação em segundo plano pode não ser adequada para todos os tipos de carga de leitura e que são necessárias outras melhorias para elevar a capacidade de processamento de gravações além dos limites do quórum.
O GitHub afirma que o próximo desafio é ordenar a pequena quantidade de dados do repositório que exige coordenação, enquanto armazena objetos imutáveis do Git sem exigir consenso entre as réplicas. A empresa planeja descrever a arquitetura final pretendida em uma próxima publicação e no GitHub Universe.
Fontes: GitHub Blog.