Migração da Datadog com IA corta custos de banco em 90%

Por que o Stream Router ficou pequeno para seu banco chave-valor

O problema da Datadog era um serviço de roteamento que virou gargalo. O Stream Router é um plano de controle interno que diz aos produtores onde gravar os dados de métricas e aos consultores onde lê-los, escolhendo o cluster Kafka, o tópico e as partições de cada ponto de dados em uma plataforma que processa mais de cem trilhões de eventos por dia.

Ele nasceu como solução para um problema mais antigo. Em 2016, o roteamento era gerido por um arquivo de configuração de três linhas, que cresceu para milhares de linhas editadas à mão. O Stream Router o substituiu por um serviço gRPC cujo caminho de gravação rodava no FoundationDB, em um modelo chave-valor.

À medida que a tabela de roteamento crescia, operações críticas esbarravam nos limites de tamanho de transação do FoundationDB. As mais exigentes levavam até 45 minutos por causa de milhares de idas e vindas sequenciais. Rotas, fluxos, estratégias de sharding e regras são relacionais por natureza, então o código puxava dezenas de milhares de entradas para os processos dos pods e fazia o papel de um banco relacional dentro do processo.

O que a Datadog mudou no modelo de dados

A solução foi um esquema relacional. Os engenheiros redesenharam o modelo de dados em torno das relações entre essas entidades, para que chaves estrangeiras no PostgreSQL impusessem regras que o código da aplicação reconstruía à mão.

A forte modularidade tornou a troca possível: o novo Stream Router implementou a mesma API no PostgreSQL em vez de no FoundationDB, sem necessidade de mudanças em outros lugares. O trabalho restante era refatorar toda a base de código do modelo antigo para o novo, e foi aí que a equipe trouxe o Claude e o Cursor.

Como o Claude e o Cursor trabalharam método por método

Os modelos trabalharam em um ciclo curto, e não sozinhos. O engenheiro Arnold Wakim descreveu assim.

"Eles não geravam código de forma autônoma: para cada método, fornecíamos a implementação antiga, o novo esquema e um teste que falhava." Arnold Wakim, engenheiro da Datadog

Os modelos produziam uma primeira versão, e os testes decidiam se estava correta. O trabalho seguiu em três fases: o Claude primeiro descreveu a intenção de cada função-chave; depois os engenheiros escreveram prompts focados para corrigir os testes que falhavam, informando o comportamento esperado e o contexto da primeira etapa; e por fim o novo serviço foi para produção em uma configuração blue/green.

Como a equipe manteve seguro o tráfego ao vivo

A segurança em produção veio de rodar os dois sistemas ao mesmo tempo. Duas instâncias independentes do Stream Router, uma apoiada no PostgreSQL e outra no FoundationDB, atendiam às mesmas requisições enquanto feature flags moviam os clientes entre elas. Um serviço validador em cada cluster comparava as respostas de roteamento e alertava a equipe de imediato se divergissem.

Onde os modelos ficaram aquém

Os modelos tinham limites claros, e Wakim os lista. Prompts de nível mais alto funcionaram mal. O Claude escreveu consultas que devolviam resultados corretos, mas faziam muito mais idas e vindas do que o necessário, e otimizações como batching, UNNEST e expressões de tabela comuns exigiram intervenção humana. Depois que os engenheiros escreveram o padrão otimizado, os modelos o repetiram nos métodos seguintes, mas nunca o descobriram sozinhos. O uso de tokens também foi alto, porque a equipe alimentou o ciclo com a saída completa dos testes, e não com trechos reduzidos.

O que a migração entregou

Os resultados medidos são da própria empresa. Operações que levavam 45 minutos caíram para cerca de um segundo, e as latências passaram de centenas de milissegundos para poucos. O armazenamento de dados ficou até 40 vezes menor, o uso de CPU e de memória diminuiu e os custos do banco caíram 90%. A Datadog diz que não teria concluído a implementação no prazo que tinha sem as ferramentas de IA.

O que isso diz às equipes que planejam uma refatoração assistida por IA

Para uma organização de engenharia, a tarefa aqui é uma refatoração grande e repetitiva de código de produção com prazo apertado. A migração da Datadog com IA sugere onde está o valor: os modelos aceleraram a digitação, enquanto a suíte de testes, o projeto modular e o validador lado a lado tornaram a velocidade segura. Wakim conclui que a força da suíte de testes decidiu até onde a equipe podia confiar no código gerado por IA. Uma equipe sem essa suíte receberia o mesmo código mais rápido, e nenhum meio de saber se estava certo.

Perguntas e respostas

Como a Datadog usou o Claude e o Cursor na migração?

Para cada método, os engenheiros deram aos modelos a implementação antiga, o novo esquema e um teste que falhava. Os modelos escreviam uma primeira versão, e os testes mostravam se estava correta.

Que resultados a migração para o PostgreSQL produziu?

A Datadog diz que as operações caíram de 45 minutos para cerca de um segundo, as latências passaram de centenas de milissegundos para poucos, o armazenamento encolheu até 40 vezes e os custos do banco caíram 90%.

O que os modelos de IA não conseguiram fazer?

Escreveram consultas corretas, mas lentas. Batching, UNNEST e expressões de tabela comuns precisaram de engenheiros humanos, e os modelos só reutilizaram esses padrões depois de vê-los.