GitHub reformula o armazenamento do Git: 5.000 agentes em um repositorio e 7.200 pushes por segundo

O Git foi criado para pessoas. Um desenvolvedor faz um commit, envia alguns pushes por dia, às vezes entra em conflito com um colega, e tudo isso representa uma carga modesta para o servidor. Os agentes rompem esse modelo: eles escrevem código em paralelo, com frequência e sem pausas para o café. O GitHub divulgou um teste que mostra até onde está disposto a levar essa mudança.

O que o GitHub anunciou

Segundo a conta oficial, em testes internos a nova arquitetura de armazenamento do Git do GitHub suportou 5.000 agentes trabalhando simultaneamente em um único repositorio. Eles enviaram 7.200 pushes por segundo. Ao mesmo tempo, o serviço continuou atendendo às solicitações de leitura com latência consistentemente baixa. A publicação em si não traz detalhes, apenas um link para o artigo. Portanto, tudo o que aparece abaixo sobre a estrutura do sistema deve ser entendido como uma base para reflexão, e não como uma reconstrução da arquitetura.

Que problema isso resolve

Imagine um cruzamento movimentado com um semáforo projetado para cinco carros por minuto. Enquanto pessoas estão dirigindo, tudo funciona. Quando 5.000 carros autônomos entram na via, começa o congestionamento. Com um repositorio acontece algo parecido: cada push atualiza referências e grava objetos, e, sob alta concorrência, as gravações começam a interferir nas leituras. Mas todos precisam ler: clonagem, CI, revisões e agentes vizinhos que baixam o código mais recente.

O principal número aqui não são os 5.000 agentes, mas a combinação simultânea de duas condições: alto volume de gravações e baixa latência de leitura. Também é possível absorver picos de gravação degradando todo o resto. A afirmação, neste caso, é que o desempenho de leitura não despencou.

Por que isso importa agora

Os fluxos de trabalho com agentes estão se afastando rapidamente do modelo em que um assistente ajuda uma pessoa. Cada vez mais, uma única pessoa inicia dezenas de tentativas paralelas de resolver uma tarefa, e cada uma opera em sua própria branch. Se a infraestrutura não sustentar essa carga, as equipes esbarrarão no armazenamento, nos limites e nas filas, e não na qualidade dos modelos.

Para equipes de produto e fundadores, isso é um sinal: as plataformas de desenvolvimento estão sendo reconstruídas para um novo usuário que não é humano. Ferramentas que tratam um agente como um cliente comum, com limites comuns, em breve se tornarão gargalos.

O que fazer na pratica

Primeiro, estime quantos pushes por minuto seu sistema de agentes realmente gera. Para a maioria das equipes, serão unidades ou dezenas, e não milhares; nesse caso, o recorde do GitHub ainda não é relevante para elas.

Segundo, verifique onde está seu gargalo atualmente. Entre as causas comuns estão conflitos de merge no mesmo arquivo, CI lento para cada commit e limites de API. O armazenamento geralmente não é a primeira restrição.

Terceiro, separe o trabalho dos agentes por branches e áreas do código. Cinco mil agentes editando o mesmo arquivo ficarão soterrados por conflitos, independentemente da velocidade do servidor.

Quarto, acompanhe como o GitHub transformará isso em um produto, em quais planos e com quais limites. Por enquanto, trata-se de um anúncio sobre testes internos.

Limitações

O teste é interno e a metodologia não foi divulgada. Não sabemos o tamanho do repositorio, o tamanho dos pushes, a proporção de alterações conflitantes nem o que “baixa latência” significa em milissegundos. Também não está claro quando e para quem esse recurso estará disponível. Portanto, a reação correta é encará-lo como um sinal da direção do desenvolvimento, mas não incorporar esses números aos planos enquanto não houver medições independentes.

A conclusão é simples. Com os agentes, o Git está deixando de ser uma ferramenta para pessoas e se transformando em um sistema de alta carga. O GitHub afirma que está se preparando para isso. Todos os demais devem pensar com antecedência em como seus processos se comportarão quando o número de pushes aumentar cem vezes.