Rubicon, do GitHub: consenso nos ponteiros, paralelismo nos objetos

O GitHub detalhou o Project Rubicon, uma nova arquitetura de armazenamento Git que, em testes internos, sustentou 5.000 agentes concorrentes e 7.200 pushes por segundo em um repositório.[7] O projeto estava em prévia privada limitada, com expansão planejada para o início de 2027.[7] Mais útil que repetir o benchmark é entender qual parte do problema a empresa decidiu coordenar.

O que muda para quem desenvolve

Rubicon separa objetos Git imutáveis do estado mutável das referências.[7] Packs e estruturas auxiliares ficam no Azure Blob Storage, enquanto referências e o manifesto de packs ficam no Ref-CAS, um serviço de log replicado.[7] Na escrita, o pack torna-se durável antes da transação que publica as referências.[7]

O Ref-CAS usa compare-and-swap com quórum e bloqueia somente as referências tocadas pela transação.[7] Branches independentes podem avançar em paralelo, enquanto atualizações concorrentes da mesma referência precisam de arbitragem.[7] Essa é a lição reaproveitável: não colocar todos os dados atrás do mesmo ponto de serialização quando apenas uma pequena parte exige acordo.

As réplicas virtuais são descartáveis e seu disco funciona como cache.[7] A manutenção também sai do caminho principal: workers compactam packs e verificam a preservação dos objetos antes de publicar o resultado.[7] Atendimento e manutenção passam a ter recursos e ritmos próprios.

Como aplicar

Em uma automação com vários agentes, experimente tarefas em branches independentes e mantenha a integração como etapa explícita. Compare o tempo gasto escrevendo objetos com o tempo de espera para integrar mudanças. Não aumente concorrência sem saber onde está a fila.

Para estudar o princípio em outro sistema, modele um catálogo de versões com blobs imutáveis e um ponteiro para a versão atual. Faça a gravação do blob antes da atualização condicional do ponteiro. Simule dois escritores e exija que apenas a atualização compatível com a versão esperada seja aceita.

Observe separadamente publicação, leitura e coleta de dados antigos. O objetivo desse experimento não é reproduzir a infraestrutura do GitHub, mas tornar verificável a diferença entre armazenar conteúdo e decidir qual conteúdo está vigente.

Cuidados e limites

O artigo relata que uma tentativa de manter todo o estado de referências em um único blob limitou a escrita, enquanto dividir em vários blobs prejudicava a leitura por exigir consultas a múltiplos segmentos.[7] Não existe uma escolha de particionamento gratuita: o padrão de acesso decide qual custo importa.

Os números divulgados são resultados do fornecedor, não garantia para qualquer repositório.[7] Recursos como trabalho sem clone completo e API de commit atômico multifile aparecem como planos.[7] E mesmo armazenamento mais rápido não é argumento suficiente para multiplicar agentes: meça também revisão, CI e integração antes de chamar mais concorrência de produtividade.

Fonte

[7] Fonte: GitHub Blog