Diferencias entre los workers light y heavy en n8n: cómo funcionan y para qué sirven
Publicado el 31.10.2025
n8n — es una potente herramienta open-source para la automatización de flujos de trabajo, que permite crear workflows complejos sin programación intensa. Uno de los mecanismos clave para escalar en n8n es el queue mode (modo de cola), donde el proceso principal (instancia principal) delega la ejecución de tareas a procesos separados, llamados workers. Los workers permiten distribuir la carga, asegurando la ejecución paralela de workflows y mejorando el rendimiento del sistema.
En la comunidad de n8n y en guías prácticas a menudo se distinguen dos tipos de workers: light workers (ligeros) y heavy workers (pesados). Aunque la documentación oficial no utiliza estos términos directamente, reflejan las diferencias en los tipos de tareas y la configuración. Los light workers están orientados a operaciones rápidas y frecuentes, y los heavy a tareas que consumen muchos recursos. En este artículo analizaremos en qué se diferencian, cómo funcionan y por qué son necesarios para un escalado efectivo.
¿Qué es queue mode en n8n?
Antes de pasar a los tipos de workers, un breve contexto. En queue mode n8n divide la responsabilidad:
- Instancia principal (main instance) — maneja la UI, API, solicitudes de webhook y triggers. No ejecuta los workflows en sí, solo los coloca en la cola en Redis (broker de mensajes).
- Workers — procesos Node.js separados que toman tareas de la cola de Redis, ejecutan los workflows y devuelven los resultados a la base de datos (se recomienda PostgreSQL).
- Webhook processors (opcional) — procesos especializados para el manejo de webhooks entrantes.
Esto permite escalar el sistema horizontalmente: agregar workers a medida que crece la carga. Redis gestiona la cola, y el parámetro concurrency (paralelismo) en los workers define cuántas tareas pueden ejecutarse simultáneamente en un worker (por defecto — 10).
Light workers: para tareas rápidas y frecuentes
Los light workers son procesos “ligeros” diseñados para manejar operaciones simples y de alta velocidad. Son ideales para escenarios con picos de carga, donde importa la rapidez y el volumen.
Características clave:
- Tipo de tareas: triggers de webhook, workflows simples con pequeño volumen de datos, llamadas API frecuentes.
- Configuración: alto concurrency (por defecto 10 o más), para procesar muchas tareas en paralelo.
- Ventajas: respuesta rápida a eventos, consumo mínimo de recursos por tarea.
- Ejemplo de uso: procesamiento de notificaciones de un bot de Telegram o integración con Stripe — miles de solicitudes pequeñas por minuto.
Nota sobre los Webhook Processors:
Se pueden desplegar procesos separados con el comando n8n webhook. Este proceso no ejecuta workflows — su tarea es aceptar rápidamente la solicitud del webhook, ponerla en la cola (por ejemplo, default o webhooks) y devolver una respuesta “OK”. La ejecución la asumirá un light worker que esté escuchando esa cola. Esto descarga la UI principal y asegura la capacidad de respuesta del sistema.
Heavy workers: para operaciones que consumen muchos recursos
Los heavy workers, por el contrario, son “pesados” — se encargan de tareas complejas y computacionalmente intensivas, donde el CPU, la memoria y I/O son críticos.
Características clave:
- Tipo de tareas: procesamiento de archivos grandes, solicitudes API masivas, pasos con IA (por ejemplo, generación de texto con LLM), o workflows con gran volumen de datos.
- Configuración: bajo concurrency (se recomienda 5 o menos), para evitar sobrecargas. Utilice Split In Batches y almacenamiento externo (por ejemplo, S3) para datos grandes.
- Ventajas: estabilidad bajo carga y protección contra caídas del sistema.
- Ejemplo de uso: automatización de procesamiento de vídeo o análisis de grandes hojas de cálculo de Google Sheets.
Los heavy workers evitan la situación en la que las tareas “pesadas” ralenticen la cola de tareas rápidas.
Cómo implementar la separación entre light y heavy
En n8n la separación no se realiza mediante tipos de procesos distintos, sino a través de colas nominadas.
Por defecto todas las tareas van a la cola default. Para separarlas:
1. Asigne el workflow a la cola adecuada
En la configuración Workflow → Settings → Queue indique el nombre de la cola:
- para tareas pesadas —
heavy_tasks; - para las ligeras —
defaultolight_tasks.
2. Inicie los heavy-workers
docker run -d \
-e QUEUES=heavy_tasks \
-e N8N_WORKER_CONCURRENCY=3 \
n8nio/n8n worker
Este worker tomará tareas únicamente de la cola heavy_tasks y procesará como máximo 3 tareas simultáneamente.
3. Inicie los light-workers
docker run -d \
-e QUEUES=default,light_tasks \
-e N8N_WORKER_CONCURRENCY=20 \
n8nio/n8n worker
Estos workers escuchan las colas para procesamiento rápido y no afectan a las tareas pesadas.
Comparación entre light y heavy workers
| Aspecto | Light Workers | Heavy Workers |
|---|---|---|
| Tipo de carga | Ligeras, frecuentes (webhooks, API) | Consume muchos recursos (archivos, IA, grandes datos) |
| Concurrency | Alto (10+) | Bajo (≤5) |
| Use case | Tráfico pico, alta frecuencia | Workflows largos y complejos |
| Optimización | Balanceo de carga | Batching, reintentos, almacenamiento externo |
| Recursos | Bajo consumo | Alto, pero controlado |
| Colas | default, light_tasks, webhooks | heavy_tasks, batching_queue |
¿Por qué es necesario?
Sin queue mode toda la carga recae en un solo proceso, y un workflow pesado puede bloquear la UI. La separación en light y heavy resuelve este problema:
- Escalabilidad — se pueden incrementar horizontalmente los workers.
- Rendimiento — las tareas pesadas no interfieren con las rápidas.
- Confiabilidad — aislamiento de fallos entre pools.
- Ahorro de recursos — se utilizan los recursos según su propósito.
Como resultado, el sistema permanece receptivo, fiable y preparado para cargas de nivel production.
Conclusión
Light y heavy workers no son categorías estrictas, sino un patrón de ingeniería que ayuda a utilizar eficazmente las capacidades del queue mode en n8n. Light — para velocidad, heavy — para estabilidad. Juntos permiten construir sistemas de automatización escalables, resilientes y económicos.
Reseñas relacionadas
Como siempre, rápido y de calidad. Para asuntos con los servidores, me dirijo a Mijaíl.
Vadim_U · Migración de n8n a otro servidor
Cliente habituado14.11.2025 · ⭐ 5/5
¡Como siempre, rápido y de calidad! Para asuntos relacionados con los servidores, me dirijo a Mijaíl.