Hola a todos,
Estoy ejecutando una plataforma n8n multitenante donde cada inquilino se conecta a API externas con diferentes límites de velocidad.
El desafío es que algunos inquilinos tienen límites muy bajos, mientras que otros tienen cuotas mucho más altas.
Configuración actual: Webhook → Cola → Trabajador → API externa
Problemas que estoy viendo:
• Algunos inquilinos alcanzan límites de velocidad mucho más rápido que otros
• Los reintentos crean picos de tráfico
• Un inquilino ocupado puede consumir una gran parte de la capacidad de los trabajadores
• Difícil hacer cumplir el uso justo entre inquilinos
Estoy considerando:
• Colas por inquilino
• Limitación de velocidad con token bucket / leaky bucket
• Contadores de Redis
• Trabajadores dedicados para inquilinos de alto volumen
Para equipos que ejecutan automatizaciones multitenante a escala:
• ¿Cómo están aplicando límites de velocidad por inquilino?
• ¿Aíslan las colas por inquilino o usan una cola compartida con limitación de velocidad?
• ¿Algún patrón recomendado para evitar que un inquilino afecte a otros mientras se mantiene un buen rendimiento?
Describe el problema/error/pregunta
¿Cuál es el mensaje de error (si corresponde)?
Por favor, comparta su flujo de trabajo
(Seleccione los nodos en su lienzo y use los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)
Comparta el resultado devuelto por el último nodo
Información sobre su configuración de n8n
- Versión de n8n:
- Base de datos (predeterminado: SQLite):
- Configuración n8n EXECUTIONS_PROCESS (predeterminado: own, main):
- Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
- Sistema operativo:
Hola @Decoure_Ryan el enfoque común es usar limitación de velocidad por inquilino en lugar de un límite global único.
Webhook → Queue → Rate Limit Check → Worker → API
Rastrear solicitudes por inquilino usando Redis o una base de datos, y procesar trabajos solo cuando ese inquilino esté dentro de su límite permitido.
Esto ayuda a Prevenir que un inquilino afecte a otros
Maneja límites de API diferentes por inquilino
Reduce picos causados por reintentos
Para inquilinos de alto volumen: Colas separadas
Trabajadores dedicados para que su tráfico no impacte a todos los demás.
¡Bienvenido @Decoure_Ryan a nuestra comunidad! Soy Jay y soy un creador verificado de n8n.
El enfoque más práctico específico de n8n aquí es usar un nodo Code antes de cada llamada a API externa para verificar y actualizar un contador por inquilino. Si estás usando Redis, almacena la clave como rate_limit:{tenantId} con una ventana de expiración que coincida con el período de reinicio de la API - incrementa en cada solicitud, y si el inquilino está por encima del límite, enruta a un nodo Wait en lugar de proceder.
Para el problema de ráfaga de reintentos: en lugar del reintentos integrado de n8n (que se activa inmediatamente y puede amplificar 429s), captura la salida de error del nodo HTTP Request y enrútala a un nodo Wait con un retraso fijo o dinámico extraído del encabezado de respuesta Retry-After, luego retrocede a la solicitud.
Si estás en modo de cola, los límites de concurrencia por flujo de trabajo te ofrecen aislamiento natural por inquilino cuando los trabajos de cada inquilino se ejecutan en un subflujo de trabajo dedicado - establece concurrency: 1 por flujo de trabajo de inquilino y la cola maneja la limitación para ti sin ninguna lógica de contador Redis.
Aquí hay algunas cosas que han funcionado a escala:
Las colas por inquilino son la decisión correcta. Las colas compartidas con limitación de velocidad suenan como si serían simples pero siempre terminan con problemas de vecino ruidoso. Una cola aislada te da verdadero aislamiento sin la lógica de prioridad compleja.
En cuanto a la implementación del token bucket, Redis es sólido, simplemente almacena una clave por inquilino usando recarga basada en TTL. Los reintentos no se disparan todos al mismo tiempo después de que se reinicia la ventana de límite de velocidad; usa backoff exponencial con jitter.
En cuanto a la asignación de workers, considera un modelo escalonado: un pequeño grupo de workers dedicados para los inquilinos de mayor volumen, workers compartidos para todos los demás. Esto evitará el sobreaprovisionamiento mientras aún proteges el rendimiento de los principales inquilinos.
Algo que a menudo se pasa por alto es instrumentar la profundidad de la cola por inquilino y el tiempo de espera, no solo los hits del límite de velocidad. Aquí es donde normalmente localizarás el verdadero cuello de botella antes de que haya un problema de SLA.
¿Qué tipo de API externas estás consultando? Algunas tienen asignaciones de ráfaga que pueden suavizar considerablemente el problema de reintentos.
El token bucket por inquilino en Redis es el instinto correcto, y la decisión de diseño clave es hacer cumplir el límite antes de que el trabajo llegue al worker, no dentro de él. Si el worker toma un trabajo y luego espera en un límite de velocidad, has inmovilizado capacidad del worker sin hacer nada, que es exactamente tu problema de “un inquilino ocupado consume la capacidad de todos”.
Entonces la forma es: webhook a cola, luego una compuerta que verifica el bucket del inquilino en Redis y solo libera el trabajo a un worker cuando ese inquilino tiene presupuesto; de lo contrario, lo reencola con un retraso. Esto impide que el backlog de un inquilino limitado bloquee a los demás.
Sobre los picos de reintentos: tus reintentos necesitan backoff por inquilino también, no uno global; de lo contrario, un inquilino que ya está en su límite reintenta contra la misma pared y amplifica el pico. Backoff exponencial con jitter, contado contra el mismo bucket.
Para una equidad real con cientos de inquilinos, colas separadas para tus pocos inquilinos con mayor volumen y una cola compartida para la cola larga es generalmente la división pragmática. El aislamiento completo de colas por inquilino es más limpio pero mucho más para operar. Uno más: pon una verificación sobre la profundidad de cola por inquilino para que cuando una empiece a acumularse más allá de un umbral, te enteres temprano, en lugar de descubrirlo cuando ese inquilino se queja de que sus trabajos están retrasados por horas.