Workers y colas: como sacamos los procesos pesados de la app principal

Estamos construyendo una app con mi socio que tiene varios procesos que toman tiempo: generacion de contenido con LLMs, generacion de video, procesamiento de imagenes y research profundo con multiples llamadas encadenadas. Al principio asumimos que con async/await el problema estaba resuelto. Node.js es asincrono, no bloquea, todo bien.

La realidad fue distinta. Bajo carga real, la app se volvia irresponsiva. Endpoints simples como login o GET de perfil empezaban a devolver timeouts. Los procesos pesados no solo tardaban ellos mismos, sino que degradaban todo lo demas que corria en el mismo proceso.

El diagnostico: el proceso de Node.js estaba consumiendo todos los recursos disponibles entre conexiones abiertas, memoria y ciclos de CPU. No era un problema de async mal escrito. Era un problema de arquitectura.

El misconception mas comun: si uso await, el hilo queda libre. Eso es parcialmente cierto para I/O liviano como queries a base de datos. Cuando el driver de base de datos responde en 5ms, el event loop hace otras cosas mientras espera. Pero no es lo que pasa con nuestros procesos pesados.

Una llamada a un LLM que tarda 45 segundos tiene una conexion HTTP abierta durante 45 segundos. Esa conexion consume un socket del pool. Si tenemos 10 requests LLM concurrentes, tenemos 10 sockets ocupados, buffers de memoria para las respuestas parciales que van llegando por streaming, y cuando el response llega completo hay procesamiento de JSON que puede ser CPU-bound. El event loop no esta libre, esta manejando todo eso.

El procesamiento de imagenes es peor: es directamente CPU-bound. Mientras el evento de procesamiento corre, el event loop esta bloqueado y ningun otro callback puede ejecutarse. Para Node.js, es como si todo el servidor se pausara.

Nuestra app tiene cuatro categorias de procesos pesados. Cada una bloquea de una forma distinta y tiene un perfil de recursos diferente. Entender esto fue clave para decidir como separarlo.

La generacion de contenido con LLMs es la mas frecuente. Cada request genera texto largo: articulos, analisis, reportes. Los modelos mas capaces pueden tardar entre 30 y 60 segundos en completar, y la respuesta puede ser varios KB de JSON. El deep research encadena 3 a 5 de estas llamadas con procesamiento intermedio entre cada una, lo que significa que una sola operacion de research puede tener el socket ocupado por 3 a 5 minutos en total.

La generacion de video es la mas lenta. Hacemos llamadas a APIs externas que tardan entre 2 y 10 minutos en responder. Despues hay que descargar el archivo resultante, que puede pesar varios cientos de MB. El procesamiento de imagenes en cambio es rapido pero CPU-bound: redimensionar, comprimir, convertir formatos. No dura mucho pero bloquea el event loop mientras corre.

La solucion es conceptualmente simple: la app principal deja de ejecutar el trabajo pesado. Cuando llega un request de generacion de video, la app encola un job en Redis y responde al cliente inmediatamente con un job ID. El cliente puede consultar el estado despues. Workers dedicados en procesos separados consumen la queue y hacen el trabajo real.

El cambio de paradigma es importante: en vez de request-response sincrono, el flujo se vuelve asincrono desde el punto de vista del cliente. La app dice 'recibi tu pedido, te aviso cuando este listo' en vez de 'esperame que lo proceso ahora'. Esto libera completamente el proceso principal.

BullMQ es una libreria de queues para Node.js construida sobre Redis. Tiene dos actores principales: Queue y Worker. La Queue es el productor: la app principal crea una instancia de Queue y llama a queue.add() con el payload del job. BullMQ persiste el job en Redis con un ID unico y lo pone en estado 'waiting'.

El Worker es el consumidor: corre en un proceso separado, se conecta a la misma Queue de Redis y procesa jobs de a uno (o de a N con concurrency configurada). Cuando termina, marca el job como 'completed' y emite un evento. Si falla, lo marca como 'failed' y BullMQ puede hacer retry automaticamente.

El estado del job vive en Redis en todo momento. Esto significa que la app principal puede consultar el estado de cualquier job en cualquier momento solo con el job ID, sin necesidad de coordinacion directa con el worker.

Una de las ventajas mas concretas del patron: el scaling es quirurgico. Si la queue de video tiene 50 jobs acumulados pero AI y Research andan bien, levanto mas workers de video. La app principal no cambia, los otros workers no cambian. Solo agrego mas consumidores de esa cola especifica.

Con Docker Compose es casi trivial: cada tipo de worker es un servicio, y el scaling se hace con replicas. El worker de video puede correr en instancias con mas memoria y mejor red para las descargas. El worker de imagenes puede correr en instancias con mas CPU. La concurrency interna de BullMQ permite ademas que un solo proceso worker procese N jobs en paralelo.

El cliente lanzo un proceso pesado y recibio un job ID. Ahora necesita saber cuando termino. Hay tres enfoques con tradeoffs distintos y nosotros pasamos por los tres en distintos momentos.

Empezamos con polling: el frontend hace GET /jobs/:id cada N segundos y la app principal consulta el estado en Redis. Simple de implementar, funciona, pero genera carga innecesaria en el servidor y la latencia de notificacion depende del intervalo. El upgrade natural fue SSE (Server-Sent Events): la app mantiene una conexion HTTP abierta y pushea el evento cuando el job completa. Latencia casi cero, mucho menos carga que polling. Webhooks los usamos para integraciones service-to-service donde no hay un frontend que espere.

Las APIs externas fallan. Mucho. Rate limits, timeouts, errores 500 esporadicos, servicios caidos por mantenimiento. En nuestra experiencia, las APIs de generacion de video son especialmente inestables. Sin una estrategia de retry solida, los jobs fallarian de forma permanente ante cualquier error transitorio.

BullMQ tiene retry built-in: cuando un job falla, se puede configurar cuantos reintentos hacer y con que estrategia de backoff. Usamos backoff exponencial para la mayoria de los workers: el primer retry a los 30 segundos, el segundo a los 2 minutos, el tercero a los 10 minutos. Esto le da tiempo a las APIs externas de recuperarse sin martillarlas.

Los jobs que agotan todos los reintentos van a la Dead Letter Queue: una cola separada donde quedan los jobs fallidos para revision manual o reprocesamiento. Tenemos un worker de monitoreo que alerta cuando algo llega a la DLQ.

Lo que describimos en este post es exactamente el patron del post anterior aplicado a un caso real. La app arranco como un monolito haciendo todo: endpoints de producto, autenticacion, generacion de contenido, procesamiento de archivos. El monitoreo de trafico (guardando metricas en DB) mostro rapidamente que los procesos pesados eran el cuello de botella: concentraban la mayor parte del tiempo de respuesta y degradaban todo lo demas.

En vez de redisenar toda la arquitectura de una vez, extrajimos primero los procesos mas impactantes: generacion AI y deep research. Estabilizamos, monitoreamos. Despues video. Despues imagenes. Cada extraccion fue un ciclo pequeno y controlado. El monolito se fue achicando, cada worker se fue estabilizando, y hoy la app principal es significativamente mas liviana y confiable.