A plataforma GitHub enfrenta um crescimento sem precedentes na intensidade das operações no Git, impulsionado pela proliferação de softwares e agentes de inteligência artificial (AI Agents) que geram fluxos contínuos e intensos de alterações e atualizações. Para lidar com as limitações físicas de capacidade energética nos data centers tradicionais e nas cadeias de suprimentos, a empresa revelou um plano arquitetural que já resultou na migração de réplicas de 99,99999% de seus repositórios para coexistirem entre seus próprios data centers e a nuvem Microsoft Azure.
O obstáculo da latência e o bloqueio de repositório completo
O GitHub explicou que os repositórios mais utilizados e modificados na plataforma — que representam a pequena fração restante de 0,00001% — enfrentavam uma barreira técnica ligada ao tempo de resposta pela rede. Ao transferir dados para a região Central US do Azure, localizada a cerca de mil milhas dos data centers da plataforma, cada conexão de rede acrescenta uma latência de aproximadamente 25 milissegundos no trajeto de ida e volta.
Na arquitetura anterior do sistema de sincronização e consenso Spokes, qualquer nova operação de escrita exigia a aplicação de um bloqueio em nível de repositório completo (Repository-wide lock) até a resposta das réplicas (Replicas). Devido à manutenção desse bloqueio global, a réplica com conexão de rede mais lenta determinava o tempo de resposta e o teto máximo de vazão de todo o repositório, gerando gargalos nos repositórios ativos que recebem frequentes envios de código por desenvolvedores e agentes de IA.
Consenso baseado em referências individuais
Para superar esse gargalo, o GitHub reformulou o mecanismo de consenso aplicando seu primeiro princípio arquitetural: "minimizar a coordenação e eliminar bloqueios desnecessários". Em vez de travar o repositório por completo durante uma atualização, o escopo do consenso e do bloqueio passou a incidir exclusivamente sobre referências individuais (Per-reference serialization), como ramificações (Branches) ou marcadores (Tags).
Como a maioria das operações de escrita concorrentes realizadas por desenvolvedores ou agentes de IA visa ramificações distintas, as modificações deixaram de esperar umas pelas outras em uma fila única. Testes internos conduzidos pela empresa sob cargas de trabalho reais registraram um aumento de 3 a 4 vezes na capacidade de absorção de escritas, além de uma queda considerável na latência.
Separação entre armazenamento e computação e adoção de armazenamento de objetos
A segunda fase abrange a aplicação do segundo princípio arquitetural: "separação do armazenamento das capacidades de computação" (Decoupling storage from compute). A maioria dos repositórios Git apresenta uma predominância massiva de leituras em relação a escritas, com uma proporção entre 100 e 1.000 operações de leitura para cada escrita. Na arquitetura antiga, operações de leitura e escrita concorriam pelos mesmos recursos e memória.
Para solucionar o problema, o GitHub integrou o armazenamento de objetos (Azure Blob Storage) como um membro virtual do conselho de consenso, denominado "Réplica Virtual de Escrita" (Virtual Write Replica). Essa réplica atua como uma esteira transitória que consolida transações e envia as alterações de forma duradoura para o armazenamento em nuvem. Uma vez confirmada a persistência, a plataforma pode provisionar um número ilimitado de réplicas virtuais de leitura (Virtual Read Replicas) escaláveis sob demanda, as quais atualizam seus caches em segundo plano sem impactar a velocidade de gravação dos dados ou a sincronização.
O que muda na prática para a infraestrutura de desenvolvimento de software?
Essa reformulação de engenharia no GitHub evidencia como sistemas distribuídos em larga escala são redesenhados para suportar rotinas automatizadas baseadas em inteligência artificial. Os principais reflexos práticos incluem:
- Elevação do teto de vazão: capacidade de agentes de IA e desenvolvedores executarem envios simultâneos intensos sem gerar bloqueios (Locks) nos grandes repositórios.
- Escalabilidade flexível de leitura: possibilidade de expandir servidores de leitura e alocar seus caches de forma independente, sem a necessidade de submissão aos pesados procedimentos de consenso.
- Continuidade operacional do sistema principal: modernização dos componentes internos do sistema Spokes, que processa mais de 100 bilhões de operações diárias, sem paralisações nos serviços ou prejuízo à integridade dos dados.