Brian Celenza, engenheiro de software principal do GitHub, publicou em 6 de outubro no blog oficial de engenharia que a empresa está reconstruindo sua camada de armazenamento Git. O motivo é direto: agentes de IA empurraram o tráfego de escrita até o limite da arquitetura existente. Em benchmarks internos, a nova arquitetura eleva o throughput de escrita em até 35 vezes.
O artigo traz uma série de números de crescimento do último ano:
| Métrica | Dado mais recente | Variação anual |
|---|---|---|
| Eventos Git por mês | 473,3 bi (agosto de 2026) | cerca de 2,2x |
| Pushes por mês | 3,35 bi | 4,9x |
| Commits por mês | 7,38 bi (setembro de 2026) | mais de 5x |
| Execuções de Actions por mês | 3,26 bi (setembro de 2026) | mais de 4x |
| PRs mesclados | sem valor absoluto informado | quase 4x |
O repositório individual mais movimentado recebeu cerca de 1 bilhão de requisições só em agosto. O artigo descreve assim o hábito de escrita dos agentes:
"An agent in a tight loop commits or checkpoints after nearly every action" (Um agente em loop fechado faz commit ou checkpoint depois de quase toda ação.)
A arquitetura antiga trava na escrita
O sistema de armazenamento de repositórios atual do GitHub se chama Spokes. Por padrão, cada repositório é salvo como cópia completa nos discos locais de vários servidores de arquivos, totalizando 5 réplicas. Quando um push atualiza uma referência, o sistema usa um protocolo de commit em três fases baseado em maioria para garantir que CI, interface web e clientes de API vejam um estado consistente do repositório.
Nesse design, as réplicas cumprem duas funções ao mesmo tempo: evitar perda de dados e distribuir requisições de leitura. O custo é que cada réplica precisa participar de toda escrita — adicionar réplicas permite suportar mais leituras, mas torna a escrita mais lenta. Na era em que desenvolvedores humanos predominavam, as leituras superavam muito as escritas, então essa troca não era um problema; com os agentes elevando a frequência de escrita, o número de réplicas se tornou o gargalo da escrita.
A nova arquitetura se divide em três partes
A primeira parte é reduzir a coordenação ao mínimo: só a atualização de referências ainda exige consenso entre as partes; armazenamento de objetos, validação e varredura de segurança passam a ser processados em paralelo.
A segunda parte é separar armazenamento e computação. A persistência fica a cargo do Azure Blob Storage, e as requisições de leitura são tratadas por um conjunto de processos worker leves. Segundo o artigo:
"Separating the two lets us scale each one independently" (Separar os dois permite escalar cada um de forma independente.)
A terceira parte isola a manutenção em segundo plano: compactação e coleta de lixo passam a rodar em processos worker dedicados, sem disputar recursos com requisições em tempo real. Mecanismos de controle como proteção de branch, revisão obrigatória, logs de auditoria e observabilidade continuam em vigor.
Uma conta rápida sobre o volume de escrita
Fazendo uma conta aproximada com mês de 30 dias, 7,38 bilhões de commits equivalem a cerca de 2.850 por segundo; 3,35 bilhões de pushes equivalem a cerca de 1.290 por segundo, contra cerca de 270 um ano atrás. Se cada push exige a participação das 5 réplicas, a arquitetura antiga teria de processar algo em torno de 6.500 escritas de réplica por segundo (estimativa, sem contar retentativas e tarefas de manutenção).
O aumento de 35x no throughput corresponde a um crescimento anual de 4,9x nos pushes, deixando, no papel, margem para alguns anos. A condição é que a curva de crescimento do tráfego de agentes não se torne ainda mais acentuada — e isso o próprio GitHub não arrisca prever.
O que o artigo não explica
Quantos repositórios já migraram para a nova arquitetura e quando ocorrerá a virada completa não são informados; também não há detalhes sobre o tamanho do repositório e o nível de concorrência usados no benchmark de 35x. Possíveis impactos para os usuários, como eventual ajuste nos limites de taxa, também não são mencionados.
O GitHub teve algumas interrupções de serviço mais longas este ano; o artigo não comenta esses incidentes nem diz se a nova arquitetura evitaria algo parecido. Celenza avisa no final que o próximo texto da série vai detalhar a arquitetura futura e o contexto por trás dessa reformulação.
Fontes: blog de engenharia do GitHub, CocoLoop; dados oficiais do GitHub foram usados para verificar os critérios de contagem mensal de commits, pushes e execuções de Actions.