Migración de Datadog con IA recorta 90% los costos

Por qué Stream Router superó su almacén de clave-valor

El problema de Datadog era un servicio de enrutamiento que se había vuelto un cuello de botella. Stream Router es un plano de control interno que dice a los productores dónde escribir los datos de métricas y a los consultadores dónde leerlos, y elige el clúster de Kafka, el tema y las particiones de cada dato en una plataforma que procesa más de cien billones de eventos por día.

Nació como solución a un problema anterior. En 2016, el enrutamiento se gestionaba con un archivo de configuración de tres líneas, que creció hasta miles de líneas editadas a mano. Stream Router lo reemplazó con un servicio gRPC cuya ruta de escritura corría sobre FoundationDB con un modelo de clave-valor.

A medida que la tabla de enrutamiento crecía, las operaciones críticas chocaron con los límites de tamaño de transacción de FoundationDB. Las más exigentes tardaban hasta 45 minutos por miles de viajes de ida y vuelta secuenciales. Las rutas, los flujos, las estrategias de fragmentación y las reglas son relacionales por naturaleza, así que el código traía decenas de miles de entradas a los procesos de los pods y actuaba como una base de datos relacional en el proceso.

Qué cambió Datadog en el modelo de datos

La solución fue un esquema relacional. Los ingenieros rediseñaron el modelo de datos en torno a las relaciones entre esas entidades, de modo que las claves foráneas de PostgreSQL pudieran hacer cumplir reglas que el código de la aplicación reconstruía a mano.

La fuerte modularidad hizo posible el cambio: el nuevo Stream Router implementó la misma API sobre PostgreSQL en lugar de FoundationDB, sin necesidad de cambios en otras partes. El trabajo restante era refactorizar toda la base de código del modelo viejo al nuevo, y ahí el equipo incorporó a Claude y Cursor.

Cómo trabajaron Claude y Cursor método por método

Los modelos trabajaron dentro de un ciclo acotado, no por su cuenta. El ingeniero Arnold Wakim lo describió así.

«No generaban código de forma autónoma: para cada método, les dábamos la implementación anterior, el nuevo esquema y una prueba fallida». — Arnold Wakim, ingeniero de Datadog

Los modelos producían un primer borrador, y las pruebas decidían si era correcto. El trabajo se hizo en tres fases: primero Claude describió la intención de cada función clave; luego los ingenieros escribieron prompts concretos para corregir las pruebas fallidas, con el comportamiento esperado y el contexto del primer paso; y por último el nuevo servicio pasó a producción en una configuración blue/green.

Cómo mantuvo el equipo seguro el tráfico en vivo

La seguridad en producción vino de ejecutar ambos sistemas a la vez. Dos instancias independientes de Stream Router, una respaldada por PostgreSQL y otra por FoundationDB, atendían las mismas solicitudes mientras los feature flags movían a los clientes entre ellas. Un servicio validador en cada clúster comparaba las respuestas de enrutamiento y alertaba al equipo de inmediato si divergían.

Dónde se quedaron cortos los modelos

Los modelos tenían límites claros, y Wakim los enumera. Los prompts de más alto nivel funcionaron mal. Claude escribió consultas que devolvían resultados correctos pero hacían muchos más viajes de ida y vuelta de los necesarios, y optimizaciones como el procesamiento por lotes, UNNEST y las expresiones de tabla comunes requirieron intervención humana. Una vez que los ingenieros escribieron el patrón optimizado, los modelos lo repitieron en métodos posteriores, pero nunca lo encontraron por sí solos. El uso de tokens también fue alto, porque el equipo alimentó el ciclo con la salida completa de las pruebas y no con extractos recortados.

Qué entregó la migración

Los resultados medidos son de la propia empresa. Las operaciones que tardaban 45 minutos bajaron a cerca de un segundo, y las latencias pasaron de cientos de milisegundos a unos pocos. El almacenamiento de datos se volvió hasta 40 veces menor, el uso de CPU y memoria disminuyó y los costos de base de datos bajaron 90%. Datadog dice que sin herramientas de IA no habría terminado la implementación en el tiempo que tenía.

Qué dice a los equipos que planean una refactorización asistida por IA

Para una organización de ingeniería, la tarea aquí es una refactorización grande y repetitiva de código de producción con una fecha límite. La migración de Datadog con IA sugiere dónde está el valor: los modelos aceleraron la escritura, mientras que el conjunto de pruebas, el diseño modular y el validador en paralelo hicieron segura esa velocidad. Wakim concluye que la solidez del conjunto de pruebas decidió hasta dónde el equipo podía confiar en el código generado por IA. Un equipo sin ese conjunto obtendría el mismo código más rápido, y ninguna forma de saber si era correcto.

Preguntas y respuestas

¿Cómo usó Datadog a Claude y Cursor en la migración?

Para cada método, los ingenieros dieron a los modelos la implementación anterior, el nuevo esquema y una prueba fallida. Los modelos escribían un primer borrador y las pruebas mostraban si era correcto.

¿Qué resultados produjo la migración a PostgreSQL?

Datadog dice que las operaciones bajaron de 45 minutos a cerca de un segundo, las latencias de cientos de milisegundos a unos pocos, el almacenamiento se redujo hasta 40 veces y los costos de base de datos bajaron 90%.

¿Qué no pudieron hacer los modelos de IA?

Escribieron consultas correctas pero lentas. El procesamiento por lotes, UNNEST y las expresiones de tabla comunes requirieron ingenieros humanos, y los modelos solo reutilizaron esos patrones después de verlos.