Por que o DynamoDB se tornou o gargalo
A API de busca da Perplexity processa uma carga de trabalho exigente: cada solicitação busca aproximadamente 100 a 120 chaves de página, normalmente em lotes de 10 a 20. Cada registro tem em média cerca de 50 KB, levando a um volume substancial de dados por consulta. Esse padrão de acesso, combinado com um índice da web em rápida expansão, expôs rapidamente as limitações de um modelo de cobrança baseado no uso.
A estrutura de custos do DynamoDB cobra cada byte lido ou gravado. À medida que o índice de dados da Perplexity crescia e o tráfego de produção se intensificava, esses custos de leitura baseados em bytes aumentavam linearmente, tornando o banco de dados gerenciado cada vez mais caro. Essa pressão econômica tornou-se um impulsionador significativo para a Perplexity reavaliar sua estratégia de banco de dados.
Além do custo, a natureza gerenciada do DynamoDB impôs limites críticos de controle. A Perplexity não conseguia ajustar comportamentos fundamentais do banco de dados para otimizar seus padrões de acesso específicos. Os engenheiros não tinham a capacidade de ditar:
- O posicionamento de partições em máquinas específicas
- A memória local alocada para cache
- Qual réplica respondia a uma solicitação de leitura
Essa falta de controle granular, particularmente sobre a seleção de réplicas, significava que uma réplica lenta poderia travar uma leitura em lote inteira, impactando significativamente a latência de cauda (tail latency) para os usuários. A Perplexity precisava de uma solução mais flexível e performática.
A réplica mais lenta definia o ritmo
As leituras em lote no DynamoDB amplificavam a latência. Uma única solicitação de busca, buscando de 100 a 120 chaves de página em lotes de 10 a 20, significava que uma réplica lenta poderia atrasar toda a solicitação, mesmo que outros registros chegassem rapidamente. Esse fenômeno, onde a operação mais lenta dita o desempenho geral, é conhecido como latência de cauda.
A Perplexity resolveu isso criando o CobbleDB, um armazenamento de chave-valor hot especializado. Desenvolvido em Rust, o CobbleDB roda sobre o RocksDB, servindo dados diretamente do armazenamento NVMe local. As chaves são agrupadas logicamente por partição, garantindo uma localidade de dados eficiente. Essa arquitetura concedeu à Perplexity controle granular sobre cache e posicionamento de dados, capacidades ausentes em serviços gerenciados.
Um roteador stateless orquestra as leituras do CobbleDB. Ele envia solicitações paralelas para múltiplas réplicas e emprega hedged reads: se uma réplica atrasa, o roteador envia imediatamente a mesma leitura para outra réplica. Essa estratégia agressiva minimiza o impacto de nós lentos, reduzindo significativamente a latência de cauda para operações em lote. Essa abordagem reduziu a latência mediana de leitura em lote de 31,4 milissegundos para 5,6 milissegundos, e a latência P99 de 123 milissegundos para apenas 24 milissegundos — uma melhoria de quase cinco vezes.
A vitória de 5x — e o que os números significam
A mudança da Perplexity para o CobbleDB melhorou drasticamente a latência de leitura em lote em produção. O tempo médio de resposta caiu de 31,4 ms no DynamoDB para apenas 5,6 ms. Ainda mais impressionante, a latência de cauda P99 — que anteriormente atrasava solicitações de busca inteiras — caiu de 123 ms para aproximadamente 24 ms, marcando um aumento de velocidade de cerca de cinco vezes.
Esse aumento de desempenho veio com uma vantagem econômica significativa. O modelo de custo interno da Perplexity projetou que o CobbleDB seria pelo menos 20% mais barato que o DynamoDB em todos os níveis de compromisso. Testes sintéticos validaram ainda mais a robustez do CobbleDB, demonstrando throughput estável de até 500.000 solicitações por segundo sem degradação de desempenho.
Embora esses resultados sejam impressionantes, eles refletem a carga de trabalho e o modelo operacional específicos da Perplexity. Sua API de busca exclusiva, caracterizada por leituras em lote de 100-120 chaves de página, com média de 50 KB cada, beneficiou-se diretamente da arquitetura personalizada do CobbleDB, incluindo o uso de hedged reads para mitigar a latência de cauda.
Este sucesso não garante universalmente que um banco de dados personalizado superará serviços gerenciados para todas as equipes ou casos de uso. A solução sob medida da Perplexity foi otimizada para suas necessidades precisas, aproveitando dois engenheiros e agentes de IA para criar um sistema exclusivamente adequado à sua escala e fatores de custo. Para mais detalhes sobre a arquitetura, leia sobre CobbleDB: Rebuilding AI Search Storage for Lower Latency and Cost.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
Dois Engenheiros, Agentes de IA e o Trade-off Oculto
O rápido desenvolvimento do CobbleDB destaca uma nova fronteira na engenharia. Aproximadamente 40.000 linhas de código Rust foram entregues em cerca de dois meses por dois engenheiros, trabalhando em conjunto com agentes de codificação de IA. Essa execução rápida ressalta o potencial do desenvolvimento aumentado por IA.
A divisão do trabalho foi fundamental. Agentes de IA lidaram com tarefas repetitivas como escrever testes, implementar correções, gerar hooks de observabilidade, produzir documentação e acompanhar follow-ups de CI/CD. Enquanto isso, os engenheiros humanos mantiveram a responsabilidade pelos elementos estratégicos:
- Design de arquitetura
- Revisão de código
- Portões de implantação
- Decisões de produção
Essa colaboração permitiu que a pequena equipe se movesse com uma velocidade incomum, concentrando a experiência humana em problemas de alto impacto.
No entanto, substituir um serviço gerenciado como o DynamoDB introduz um trade-off operacional significativo. A Perplexity agora assume diretamente a responsabilidade por falhas de hardware, backups de dados e garantia de confiabilidade contínua. Embora este modelo ofereça controle e desempenho inigualáveis para cargas de trabalho especializadas de hiperescala, ele exige um nível de maturidade operacional e compromisso de recursos que a maioria das startups não pode arcar. O sucesso do CobbleDB é um testemunho da engenharia sob medida, mas vem com o custo oculto de um aumento na carga operacional.
Perguntas Frequentes
O que é o CobbleDB?
O CobbleDB é o armazenamento chave-valor interno da Perplexity, criado para servir dados de busca com menor latência e custo do que sua configuração anterior no DynamoDB.
Como o CobbleDB reduziu a latência?
Ele usa RocksDB em NVMe local e leituras de réplicas paralelas, com hedged reads que tentam novamente uma solicitação lenta em outra réplica.
Quanto o CobbleDB foi mais rápido que o DynamoDB?
A latência mediana relatada de leitura em lote caiu de 31,4 ms para 5,6 ms, enquanto a latência P99 caiu de 123 ms para cerca de 24 ms.
Os agentes de IA construíram o CobbleDB de forma autônoma?
Não. Os agentes auxiliaram em tarefas como testes, correções, monitoramento e documentação, enquanto os engenheiros projetaram o sistema, revisaram as alterações e controlaram os lançamentos em produção.