Cursor cria storage de Git em escala com S3 e write-ahead log
O problema de hospedar Git em escala
O Git foi projetado como sistema distribuído para o desenvolvimento do kernel Linux, mas na prática a maioria dos projetos depende de um host centralizado. Hospedar repositórios Git em escala é difícil por causa dos packfiles - arquivos binários compactados que armazenam objetos de forma aleatória e frequentemente como deltas sobre outros objetos. Isso gera padrões de leitura aleatória incompatíveis com sistemas de arquivos de rede e dificulta a distribuição do armazenamento.
O texto examina três abordagens históricas: distribuir os objetos (tentada pelo Google com uma tabela hash distribuída, abandonada pela lentidão de clones), distribuir o sistema de arquivos (tentativa inicial do GitHub com NFS, GFS e DRBD, todas insatisfatórias) e distribuir o próprio Git no nível da aplicação.
Spokes: o padrão do setor
O GitHub desenvolveu por volta de 2013 o Spokes, que replica repositórios Git inteiros em discos NVMe locais e usa commit em três fases (3PC) para garantir consistência total entre réplicas. O sistema funciona bem, mas tem limitações que se tornaram críticas: o 3PC não escala horizontalmente (a latência é limitada pelo nó mais lento), exige no mínimo três réplicas por repositório (desperdício para repositórios pequenos ou ociosos criados por agentes) e demanda operação complexa com tabelas de roteamento e verificação constante de integridade.
Continuity: a solução da Cursor
A Cursor desenvolveu o Continuity, um sistema de armazenamento Git cujo primitivo central é um write-ahead log (WAL) armazenado no S3. Cada push é persistido como entrada de WAL antes de ser confirmado, garantindo linearizabilidade. A fonte da verdade é o WAL no S3, não os repositórios em disco - estes funcionam como cache aquecido.
O sistema elimina a necessidade de consenso distribuído: qualquer servidor pode atuar como primário, e a sincronização do índice WAL usa operações atômicas de compare-and-swap no S3. O roteamento usa hashing de rendezvous, sem banco de dados externo. A replicação é otimista via pacotes UDP de gossip; cada réplica verifica consistência com GETs condicionais no S3 (resposta 304 significa que está atualizada).
Resultados e implicações
Com S3 Standard, o sistema sustenta até 120 pushes/s; com S3 Express One Zone, ultrapassa 300 pushes/s. Testes com até 100 réplicas mostraram escalonamento linear para leituras sem regressão em pushes. A compactação é realizada apenas pelo primário, e as réplicas baixam os packs já compactados, trocando CPU por largura de banda.
O WAL como fonte da verdade permite auditoria completa de todos os estados do repositório, reversão de operações e procedência total dos dados. O texto contextualiza que agentes de IA intensificaram a pressão sobre infraestrutura Git - mais código, mais PRs, mais execuções de CI - e que o Continuity foi projetado para escalar em ambas as direções: muitas réplicas para monorepos grandes e uma única réplica (ou nenhuma) para repositórios pequenos e descartáveis.