Datadog redujo el tiempo de ejecución de Stream Router de 45 minutos a un segundo

Datadog redujo las operaciones de Stream Router de 45 minutos a aproximadamente un segundo y disminuyó los costos de la base de datos en un 90% después de migrar la API de la métrica de FoundationDB a PostgreSQL. La migración utilizó Claude y Cursor para refactorizar el código de la aplicación método por método, en lugar de comenzar desde cero.

Stream Router, parte del flujo de métricas de Datadog, era una API eventualmente coherente respaldada por FoundationDB. A medida que expandían las tablas de enrutamiento, la base de datos de clave-valor encontró límites de tamaño de transacción, lo que llevó a operaciones que tardaban hasta 45 minutos. La capa de almacenamiento carecía de construcciones relacionales, lo que obligaba al código de la aplicación a extraer decenas de miles de entradas en la memoria y reconstruir la lógica de claves foráneas en proceso. El equipo rediseñó el esquema en torno a relaciones de entidades de dominio, movió el backend a PostgreSQL y agregó DuckDB para análisis, permitiendo que la base de datos maneje claves foráneas y uniones.

La reescritura asistida por IA no fue autónoma. Ingenieros proporcionaron a Claude la implementación antigua, el nuevo esquema y una prueba fallida, utilizando la salida del modelo como un borrador inicial y el conjunto de pruebas como la puerta de aceptación. El proceso incluyó tres fases: animar a Claude a articular la intención de cada función existente, crear prompts enfocados para corregir pruebas fallidas contra el nuevo esquema y desplegar la implementación respaldada por PostgreSQL junto con la versión heredada de FoundationDB en una configuración azul/verde. Un servicio validador dedicado comparaba continuamente las respuestas de enrutamiento entre las dos pilas y alertaba en caso de divergencia, mientras que las banderas de características gestionaban el corte de tráfico.

Los beneficios operativos fueron significativos. Las latencias disminuyeron de cientos de milisegundos a milisegundos de una sola cifra, y el pie de imprenta de almacenamiento disminuyó en hasta 40 veces. Según un informe de InfoQ sobre la cuenta del ingeniero de Datadog Arnold Wakim, las ganancias resultaron de eliminar la reconstrucción relacional en proceso y aprovechar el planificador de consultas de PostgreSQL.

Sin embargo, las herramientas de IA introdujeron fricción. Los prompts de alto nivel eran ineficaces; el modelo solo producía código enviable cuando se enfocó en métodos individuales. Claude emitía consultas correctas pero subóptimas que iniciaban viajes de ida y vuelta innecesarios. Las optimizaciones SQL nicho requerían que los ingenieros humanos escribieran el primer ejemplo; el modelo podía replicar un patrón una vez mostrado pero nunca lo descubrió de forma independiente. Los costos de tokens aumentaron debido a alimentar volcados completos de salida de pruebas en la ventana de contexto en lugar de extractos recortados, y cada iteración requería pasar la salida de la prueba, el contexto del código y la información del esquema de vuelta al modelo.

El verdadero facilitador fue la rigurosidad de la ingeniería circundante. Una fuerte modularidad del código permitió que la implementación de PostgreSQL satisfaciera la misma API sin forzar cambios en otros lugares. El conjunto de pruebas existente proporcionó el criterio binario de aprobación/rechazo que hizo que los cambios generados por la IA fueran confiables. La infraestructura paralela con validación continua y banderas de características proporcionó los raíles de seguridad. Sin estos, la salida de la IA habría sido incombinable.