Netflix reescribe Conductor para 420 millones de workflows al mes y flujos diez veces mayores
La versión 4.0 separa metadatos de datos de tareas, saca la evaluación del camino síncrono y elimina los locks: de 2.500 tareas por workflow a 30.000 y un 40% menos de latencia p99.
Netflix ha reescrito Conductor, su motor de orquestación de workflows, para aguantar la escala que tiene hoy dentro de la empresa: unas 200.000 definiciones repartidas en 150 aplicaciones y alrededor de 420 millones de ejecuciones al mes. La versión 4.0 sube el tamaño de workflow soportado de unas 2.500 tareas a 30.000 y recorta cerca de un 40% la latencia p99 de evaluación. El motor mueve procesos de las áreas de Content y Studio Engineering, Ads y Games.
El cuello de botella estaba en la evaluación
Las versiones anteriores cargaban el estado completo del workflow en memoria cada vez que había que evaluarlo. Con workflows pequeños eso se sostiene; cuando crecen, no. El rediseño separa los metadatos del workflow de los datos de tareas y de usuario, guarda las tareas por su cuenta y hace que el evaluador trabaje sobre un blueprint ligero, cargando solo los datos de la tarea que necesita para la siguiente decisión.
No es una hipótesis: los problemas venían de lejos en la propia comunidad. En 2022 un usuario reportó 55.745 workflows y 310.000 tareas llevando el heap de la JVM a 5 GB. Aravind Ramkumar, mantenedor de Conductor en Netflix, confirmó entonces que el motor cargaba el workflow en ejecución entero para evaluarlo y que cargar solo las porciones necesarias estaba en la hoja de ruta. Otro hilo de ese mismo año describía un workflow de 1,7 MB con casi 5.000 entradas de tarea: guardar la definición tardaba cerca de dos minutos y recargarla desde la base de datos se comía el tiempo de ejecución. En otro caso, con 25.000 a 30.000 workflows activos, las colas de tareas HTTP se acumulaban y la recomendación fue escalar en horizontal, no subir el número de polling.
Con 4.0 desaparece el locking en la coordinación del estado de tareas: los estados pendientes y terminales se guardan por separado y se reconcilian en la capa de aplicación, con el terminal ganando. La evaluación sale del camino síncrono y los updates van a colas exclusivas de Timestone, que los procesa en orden y de forma asíncrona. Netflix cifra el resultado: los intentos fallidos de adquirir un lock, que llegaban a unos 2.700 por intervalo en momentos de contención, se quedan prácticamente en cero.
El resto de la arquitectura viene de lejos. Los datos de ejecución migraron de Dynomite a Cassandra, las entradas y salidas grandes de tareas se movieron a Amazon S3, DynoQueues se sustituyó por Timestone y más tarde entró Kafka para desacoplar el indexado del camino de ejecución, con Elasticsearch e Iceberg cubriendo indexado y almacenamiento a largo plazo. La versión 4.0 añade además controles de concurrencia nativos, asignación dinámica de workers y un SDK de Java con tipado seguro, que Ads ya usa para ingestión de creatividades y workflows de Data Clean Room.
Netflix espera que la demanda se multiplique por cinco según empuja hacia contenido en directo, juegos y podcasts. Para quien no esté dentro de la casa, el detalle incómodo es otro: el repositorio OSS público de Conductor dejó de recibir mantenimiento en diciembre de 2023, cuando la compañía se volcó en su fork interno. Los módulos y extensiones de la comunidad siguen vivos en un repositorio aparte, pero lo que se despliega desde el proyecto abierto está sobre una base congelada y todo lo que cuenta de 4.0 se ha contado desde dentro.
