Datadog reduz tempo de execução do Stream Router de 45 minutos para um segundo

Datadog reduziu as operações do Stream Router de 45 minutos para aproximadamente um segundo e diminuiu os custos do banco de dados em 90% após migrar a API do pipeline de métricas do FoundationDB para PostgreSQL. A migração utilizou Claude e Cursor para refatorar o código do aplicativo método por método, em vez de começar do zero.

Stream Router, parte do pipeline de métricas do Datadog, era uma API eventualmente consistente apoiada pelo FoundationDB. À medida que as tabelas de roteamento expandiam, o banco de dados de chave-valor encontrou limites de tamanho de transação, levando a operações que levavam até 45 minutos. A camada de armazenamento carecia de construções relacionais, forçando o código do aplicativo a buscar dezenas de milhares de entradas na memória e reconstruir a lógica de chave estrangeira em processo. A equipe rediseñou o esquema em torno de relacionamentos de entidades de domínio, moveu o backend para PostgreSQL e adicionou DuckDB para análise, permitindo que o banco de dados manipulasse chaves estrangeiras e junções.

A reescrita assistida por IA não foi autônoma. Engenheiros forneciam ao Claude a implementação antiga, o novo esquema e um teste com falha, usando a saída do modelo como um rascunho inicial e o conjunto de testes como o portão de aceitação. O processo incluiu três fases: incentivando Claude a articular a intenção de cada função existente, criando prompts focados para corrigir testes com falha contra o novo esquema e implantando a implementação apoiada por PostgreSQL ao lado da versão herdada do FoundationDB em uma configuração azul/verde. Um serviço de validador dedicado comparava continuamente as respostas de roteamento entre as duas pilhas e alertava sobre divergências, enquanto flags de recursos gerenciavam a transição do tráfego.

Os benefícios operacionais foram significativos. As latências caíram de milhares de milissegundos para milissegundos de um dígito, e o pé de armazenamento diminuiu em até 40x. De acordo com um relatório do InfoQ sobre a conta do engenheiro do Datadog Arnold Wakim, as ganâncias resultaram da eliminação da reconstrução relacional em processo e do aproveitamento do planejador de consultas do PostgreSQL.

No entanto, as ferramentas de IA introduziram atrito. Prompts de alto nível eram ineficazes; o modelo produzia código embarcável apenas quando limitado a métodos individuais. Claude emitia consultas corretas, mas subótimas, que iniciavam viagens de ida e volta desnecessárias. Otimizações SQL nicho exigiam que engenheiros humanos escrevessem o primeiro exemplo; o modelo poderia replicar um padrão uma vez mostrado, mas nunca o descobriu independentemente. Os custos de token aumentaram devido ao fornecimento de despejo completo de saída de teste na janela de contexto em vez de trechos cortados, e cada iteração exigia a passagem de saída de teste, contexto de código e informações de esquema de volta ao modelo.

O verdadeiro facilitador foi a rigorosa engenharia ao redor. Uma forte modularidade de código permitiu que a implementação do PostgreSQL atendesse à mesma API sem forçar mudanças em outros lugares. O conjunto de testes abrangente existente forneceu o critério binário de passagem/falha que tornou as alterações geradas pela IA confiáveis. A infraestrutura paralela com validação contínua e flags de recursos forneceu os guard-rails de segurança. Sem eles, a saída da IA teria sido inmergeável.