Perplexity troca DynamoDB por CobbleDB em Rust e reduz latência em 5x

A Perplexity reduziu a latência mediana de leitura em lote de 31,4 ms para 5,60 ms ao trocar o Amazon DynamoDB pelo CobbleDB, um banco key-value distribuído interno escrito em Rust. A migração do tier de serving de busca também cortou ao menos 20% dos custos de armazenamento, segundo a reportagem da InfoQ. O movimento responde a um padrão de acesso específico de respostas para modelos de linguagem, que leem documentos grandes em rajadas paralelas e estouram os limites econômicos de um banco gerenciado.

Por que o DynamoDB não servia para servir LLMs

Cada consulta enviada ao Perplexity gera entre 100 e 120 chaves de páginas. O serviço de retrieval divide essas chaves em lotes paralelos de 10 a 20 itens. Diferente de uma busca tradicional, que devolve metadados curtos, o retrieval para LLM precisa extrair passagens completas e embeddings vetoriais densos — resultando em payloads médios de aproximadamente 50 KB.

Acima de 200 mil requests por segundo, o modelo de preços do DynamoDB, que cobra por byte transferido, tornou-se financeiramente insustentável. O banco também opera como caixa-preta: não expõe posicionamento de partições, políticas de memória cache ou roteamento de réplicas. Sem essa visibilidade, os engenheiros não conseguiam evitar picos de tail latency causados por leituras não cacheadas, saltos de rede entre zonas e réplicas atrasadas. Jobs de reprocessamento disparados por mudanças de chunking ou novos modelos de embedding também injetavam escrita pesada no DynamoDB, criando contenção com o tráfego ao vivo.

A arquitetura de três peças: Pillar, Lorry e CobbleDB

A Perplexity dividiu o armazenamento em três sistemas especializados. O Pillar roda sobre YTsaurus em discos mecânicos de alta capacidade e mantém famílias de tabelas versionadas para metadados de páginas, passagens e vetores. Transações atômicas do YTsaurus garantem que atualizações de crawl, mudanças de estado e filas de exportação commitam juntas.

O Lorry é um consumidor stateless de filas que agrupa exportações do Pillar em arquivos de lote alinhados à partição, armazena os payloads no Amazon S3 e publica avisos de metadados no CobbleDB. Os workers do CobbleDB puxam e ingerem esses lotes do S3 de forma independente, isolando os nós de serving do pipeline de escrita. Cada partição mantém três réplicas distribuídas em nós distintos, e o daemon usa RocksDB como engine local com cache memory-mapped e NVMe.

Um query router sem estado mapeia IDs hasheados de páginas para partições e coordena a execução das leituras. Para reduzir tráfego de rede, ele roteia para réplicas na mesma availability zone. Se a réplica alvo demorar, o router dispara uma leitura especulativa para outra réplica em outro nó. Dentro do nó, as chaves são lidas simultaneamente pela interface MultiGet do RocksDB, eliminando overhead de round-trip. O banco não usa protocolos de transação distribuída nem consenso síncrono: como o serving tolera leve defasagem de réplica, as réplicas aplicam atualizações de forma assíncrona.

Resultados de produção: 5x na mediana e p99 abaixo de 25 ms

As medições ao vivo mostram a escala da melhoria. A latência mediana de leitura em lote caiu de 31,4 ms para 5,60 ms. O p90 foi de 56,7 ms para 9,77 ms, e o p99 recuou de 123 ms para 24,2 ms. Em benchmarks sintéticos com payloads de até 100 KB, o throughput se manteve consistente até 500 mil requests por segundo, conforme os números publicados pela InfoQ.

Os trade-offs de abandonar um serviço gerenciado

Substituir o DynamoDB transfere para os SREs internos responsabilidades que antes eram da AWS: ciclo de vida de nós, verificação de backups e rebalanceamento de partições. As aplicações também precisam conviver com consistência eventual, já que as réplicas ingerem lotes em intervalos diferentes. Retirar consenso síncrono reduz overhead operacional, mas exige assumir esse risco no desenho do sistema.

O CEO Aravind Srinivas afirmou que as 40 mil linhas de Rust do CobbleDB foram construídas em dois meses por dois engenheiros de sistemas, trabalhando com um enxame autônomo de agentes de IA para testes de integração, monitoramento de builds e runbooks operacionais. A Perplexity indicou planos de abrir o código do CobbleDB em uma versão futura. A troca faz sentido para times com tráfego intenso de leitura em lote e payloads grandes; para cargas convencionais de metadados ou volumes menores, o custo de operar o banco próprio pode superar a economia de armazenamento e latência.