Cursor usa write-ahead log em S3 para escalar Git a mais de 300 pushes por segundo

A Cursor, empresa por trás do editor de código com IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → de mesmo nome, publicou detalhes de uma nova arquitetura de armazenamento Git chamada Continuity. Segundo reportagem da InfoQ de 30 de setembro de 2026, o sistema usa um write-ahead log (WAL) sustentado pelo S3 como fonte da verdade, no lugar da coordenação entre réplicas que arquiteturas tradicionais de hospedagem Git usam para garantir consistência.

Os números reportados chamam atenção: em testes sintéticos, a Cursor registrou escalonamento linear de leitura com até 100 réplicas e mais de 300 pushes por segundo usando o S3 Express One Zone. Para qualquer equipe que já viu um monorepo travar sob carga de CI ou um sistema de agentes de código gerando dezenas de repositórios pequenos por hora, o problema que a Cursor resolveu é reconhecível.

O gargalo que motivou o redesenho

Hospedagem de Git em escala historicamente depende de repositórios Git locais e packfiles replicados. A arquitetura Spokes, do GitHub, mantém múltiplas réplicas NVMe e usa commit em três fases para atualizar referências. O modelo funciona: réplicas ficam sincronizadas e leituras podem ser servidas de qualquer uma delas.

O problema aparece quando o número de réplicas cresce. Coordenação em três fases significa que, quanto mais réplicas participam de uma escrita, maior o overhead para confirmar que todas concordam antes de reconhecer o push. Esse custo escala mal justamente no cenário que ferramentas de IA e CI intensivo empurram: muitos repositórios pequenos ou um monorepo com centenas de pipelines rodando ao mesmo tempo.

Como o Continuity muda o modelo

Em vez de replicar dados entre nós e coordenar cada escrita, o Continuity trata o S3 como a fonte da verdade e os repositórios locais em NVMe como cache aquecido. Os dados de um push vão para o S3 e a atualização de referência correspondente é registrada no WAL; o push só é confirmado depois que esses dados estão persistidos, o que garante durabilidade antes do reconhecimento ao cliente.

A engenharia por trás disso combina várias técnicas específicas:

• Batching de operações: agrupa escritas para reduzir o impacto da latência de PUT no S3 sobre o throughput geral.
• Rendezvous hashing: seleciona os nós preferenciais para cada repositório, sem exigir coordenação centralizada.
• Compare-and-swap atômico no S3: permite que qualquer servidor aceite um push, já que a consistência é garantida pelo próprio armazenamento e não por um coordenador de réplicas.
• Gossip via UDP: propaga atualizações do WAL entre nós de forma assíncrona, com leituras condicionais no S3 servindo de verificação, levando, segundo a Cursor, menos de 10 milissegundos em média.

Um repositório pode ser reconstruído (materializado) diretamente do WAL quando a cópia local não está disponível. E, segundo a empresa, a perda de mensagens de gossip não compromete a correção do sistema, porque o S3 continua sendo a fonte da verdade, independentemente do que os nós souberem uns dos outros em tempo real.

Git tratado como banco de dados

O desenho levantou comparações diretas com sistemas de banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →. Maksim Al Dandan, engenheiro de software sênior, descreveu a abordagem como tratar armazenamento Git como um banco de dados, apontando consistência de push, transações de force-push e recuperação para um ponto no tempo como questões relevantes para esse modelo, segundo a InfoQ.

Vicent Martí, engenheiro da Cursor, descreveu os repositórios NVMe locais como caches aquecidos em vez de cópias autoritativas, reforçando que a fonte de verdade real é o S3 e não o disco local de nenhum servidor específico.

Casey Lee, CTO da Liatrio e ex-engenheiro da AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps →, destacou a mudança arquitetural de colocar o WAL no S3 como fonte da verdade com NVMe local servindo apenas como cache. Lee também observou, segundo a InfoQ, que os números de desempenho publicados pela Cursor ainda não foram verificados de forma independente por terceiros. É um ponto que vale reter: os benchmarks vêm da própria empresa, testados no monorepo interno da Cursor (chamado everysphere), e não em ambiente auditado externamente.

Os números em contexto

Nos testes sintéticos com o monorepo everysphere, a Cursor reporta até 120 pushes por segundo usando S3 Standard e mais de 300 pushes por segundo com S3 Express One Zone, camada de armazenamento da AWS otimizada para latência mais baixa. Na taxa mais alta, o gargalo deixou de ser o armazenamento e passou a ser a compactação de Git, que segundo a empresa é feita só pelo nó primário, com réplicas baixando os pacotes resultantes do S3.

Esse detalhe é relevante: a Cursor trocou coordenação de réplicas por banda extra e validação assíncrona contra o armazenamento, mas não eliminou gargalos, apenas os moveu. A empresa afirma que os pushes testados foram linearizáveis e persistidos em armazenamento externo antes da confirmação, e que os clones permaneceram totalmente consistentes.

O que muda para quem constrói infraestrutura

O caso do Continuity é um estudo de caso de um padrão que aparece cada vez mais em sistemas distribuídos: mover o limite de consistência da camada de réplicas para um armazenamento de objetos durável, como o S3, e deixar que os nós locais convirjam de forma independente sobre esse estado compartilhado. Isso troca coordenação síncrona por propagação assíncrona, validação de armazenamento e consumo maior de banda.

Para equipes que operam plataformas com muitos repositórios pequenos, seja por causa de agentes de código gerando projetos automaticamente ou de monorepos com centenas de pipelines de CI simultâneos, a lição prática não é necessariamente replicar o Continuity, mas reconhecer o mesmo tipo de decisão de design: onde exatamente fica a fonte da verdade, e o que pode ser tratado como cache descartável e reconstruível a partir dela. É a mesma pergunta que sistemas de banco de dados distribuído já fazem há anos, agora aplicada à camada de armazenamento Git.

A ressalva de Casey Lee sobre a falta de verificação independente dos números vale como cautela para quem for avaliar essa abordagem para uso próprio: os resultados existem, mas ainda não passaram pelo escrutínio externo que benchmarks desse tipo costumam receber quando adotados fora da empresa que os produziu.

Fonte: InfoQ