GitHub em escala de agentes: separar durabilidade e leitura evita cobrar cada réplica na escrita

O GitHub descreveu um redesenho da infraestrutura Git para suportar mais concorrência de agentes e CI.[9] A atividade passou de 218,2 bilhões de eventos mensais em setembro de 2025 para 473,3 bilhões em agosto de 2026.[9] A empresa relata até 35 vezes mais throughput de escrita em testes internos da nova abordagem.[9] O que interessa como arquitetura não é copiar essa escala, mas entender onde a coordenação deve ficar.

O que muda para quem desenvolve

Na arquitetura atual, o Spokes mantém cópias completas em discos locais, normalmente cinco, e usa um protocolo de commit em três fases com quórum para atualizar referências.[9] Essas cópias participam tanto da durabilidade quanto da capacidade de atendimento.[9] Acrescentar réplicas para servir leituras aumenta também o trabalho de cada escrita.[9]

A nova abordagem concentra a coordenação na atualização da referência Git.[9] Armazenamento de objetos, verificação de conectividade e varredura de segredos podem trabalhar em paralelo a outras escritas.[9] Compactação e coleta de lixo passam a workers separados dos que atendem requisições.[9]

Os dados autoritativos ficam em Azure Blob Storage, enquanto workers de computação atendem leituras usando caches.[9] Isso permite ampliar leitura sem criar mais cópias duráveis participantes de toda escrita.[9]

Minha leitura é que o desenho separa três obrigações que não precisam escalar juntas: preservar dados, atender tráfego e executar manutenção. Em um serviço menor, a mesma pergunta vale para índices de busca ou documentos: cada réplica acrescentada para aliviar leitura está impondo coordenação desnecessária à escrita?

Como aplicar

Antes de aumentar a concorrência dos agentes, desenhe o caminho entre uma alteração e seus efeitos. Liste commits, pushes, execuções de CI e disputas pela mesma branch. Diferencie a unidade de trabalho útil do checkpoint automático.

Uma avaliação verificável pode usar um repositório descartável e uma cópia isolada do pipeline:

1. Execute uma tarefa representativa com concorrência controlada.
2. Registre a quantidade de eventos que ela provoca e o tempo até o resultado utilizável.
3. Compare checkpoints excessivos com agrupamento de mudanças que preserve a possibilidade de revisão.
4. Observe separadamente tempo de escrita, espera na fila e trabalho repetido do CI.

Não faça um teste de saturação contra a plataforma pública para validar uma hipótese local. O objetivo é descobrir desperdício no seu fluxo. Branches isoladas, limites de concorrência e critérios claros de merge são opções a avaliar, não uma receita universal.

Cuidados e limites

O GitHub informa que a migração ocorre com a plataforma em funcionamento e deve preservar histórico, revisão, proteção de branches, auditoria e controles humanos.[9] O ganho divulgado vem de testes internos e não é promessa de desempenho já recebido por todos os usuários.[9]

Separar armazenamento e computação também exige definir o que é autoritativo e como um cache é reconstruído. Não remova consistência para obter um gráfico melhor. A lição é reduzir coordenação onde ela não protege um contrato necessário, conservando-a onde uma atualização realmente exige acordo.

Fonte

[9] Fonte: GitHub Blog. Data/hora no feed: 06/10/2026 às 17:57:56.