Gestionar límites de velocidad en flujos de trabajo paralelos sin perder rendimiento

Preguntas
1

Hola a todos, estoy tratando con un problema de escalado más avanzado y me vendría bien algo de orientación.
Tengo múltiples workflows ejecutándose en paralelo (activados por webhooks y cron) que todos llaman a la misma API externa, que tiene límites de velocidad estrictos (por ejemplo, 100 solicitudes por minuto). A medida que crece el uso, estoy empezando a recibir errores 429, y los reintentos están empeorando las cosas al crear picos.
La configuración actual se ve así:
Webhook/Cron → Split In Batches → HTTP Request → Process
Ahora mismo:
Cada workflow maneja sus propios reintentos
No hay consciencia compartida de los límites de velocidad
Ocasionalmente, los picos exceden los límites de la API
Ejemplo de lógica de reintento:
if ($json.statusCode === 429) {
await new Promise(resolve => setTimeout(resolve, 1000));
return $input.all();
}
El problema:
Múltiples workflows reintentan al mismo tiempo → efecto de rebaño ensordecedor
Ralentizar un workflow no soluciona los otros
Necesito un control de límite de velocidad global, no por workflow
Estoy considerando:
Usar una cola (Redis / Bull)
Centralizar llamadas de API en un único workflow
Constructor de un limitador de velocidad personalizado con estado compartido

Describe el problema/error/pregunta

¿Cuál es el mejor patrón en n8n para manejar limitación de velocidad global en múltiples workflows mientras se mantiene un buen rendimiento?

¿Cuál es el mensaje de error (si hay alguno)?

Por favor, comparte tu workflow

(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el workflow.)

Comparte el resultado devuelto por el último nodo

Información sobre tu configuración de n8n

  • Versión de n8n:
  • Base de datos (por defecto: SQLite):
  • Configuración n8n EXECUTIONS_PROCESS (por defecto: own, main):
  • Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
  • Sistema operativo:
3

Hola @Roseline Te estás encontrando con un problema clásico de límite de velocidad y tu configuración actual (reintentos por flujo de trabajo) siempre causará picos. Cada flujo de trabajo actúa de forma independiente, por lo que los reintentos ocurren al mismo tiempo → tormentas de 429.

Intenta Centralizar las llamadas a la API

En lugar de permitir que cada flujo de trabajo acceda a la API:

Todos los flujos de trabajo → Cola → Trabajador único → Solicitud HTTP → Procesar

Puedes Crear un flujo de trabajo “trabajador de API”
• Otros flujos de trabajo envían solicitudes a él (Webhook / Ejecutar flujo de trabajo)
• El trabajador procesa solicitudes una por una o en lotes controlados

O utiliza Utiliza Redis / sistema de colas
• Introduce trabajos en la cola
• El trabajador extrae a una velocidad fija (p. ej., 100/min)

4

Gracias por las sugerencias, puedo ver que es un límite de velocidad global

5

Gracias por las sugerencias @Niffzy

6

El enfoque de flujo centralizado es definitivamente la solución más limpia. Una cosa que vale la pena añadir a ese patrón: usa un nodo Wait con un retraso calculado en lugar de uno fijo.

Si tu API permite 100 req/min, puedes calcular el retraso por solicitud como (60 / 100) * 1000 = 600ms. Entonces cada llamada al despachador central simplemente espera 600ms antes de pasar. Sin “thundering herd”, sin necesidad de estado Redis compartido, y el rendimiento se mantiene predecible.

Para mayor resiliencia aún, también puedes añadir el patrón de “circuit breaker” - si recibes 3 errores 429 consecutivos, deja de enviar durante 60s completos antes de reanudar. Esto te protege durante cualquier ráfaga inesperada.

¡Espero que te ayude!

– Nguyen Thieu Toan (Jay Nguyen) - n8n Verified Creator