Gerenciando Limites de Taxa em Fluxos de Trabalho Paralelos Sem Perder Throughput

Perguntas
1

Oi pessoal, estou lidando com um problema de scaling mais avançado e gostaria de orientação.
Tenho múltiplos workflows rodando em paralelo (disparados por webhooks e cron) que todos chamam a mesma API externa, que tem limites de taxa rigorosos (por exemplo, 100 requisições por minuto). Conforme o uso cresce, estou começando a receber erros 429, e as tentativas de retry estão piorando as coisas ao criar picos.
A configuração atual parece:
Webhook/Cron → Split In Batches → HTTP Request → Process
Neste momento:
Cada workflow lida com seus próprios retries
Nenhuma consciência compartilhada dos limites de taxa
Ocasionais picos excedem os limites da API
Exemplo de lógica de retry:
if ($json.statusCode === 429) {
await new Promise(resolve => setTimeout(resolve, 1000));
return $input.all();
}
O problema:
Múltiplos workflows fazem retry ao mesmo tempo → efeito de rebanho trovejante
Desacelerar um workflow não resolve os outros
Eu preciso de controle de limite de taxa global, não por workflow
Estou considerando:
Usar uma fila (Redis / Bull)
Centralizar chamadas da API em um único workflow
Construir um rate limiter customizado com estado compartilhado

Descreva o problema/erro/pergunta

Qual é o melhor padrão no n8n para lidar com limite de taxa global em múltiplos workflows mantendo uma boa taxa de transferência?

Qual é a mensagem de erro (se houver)?

Por favor, compartilhe seu workflow

(Selecione os nós no seu canvas e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)

Compartilhe o resultado retornado pelo último nó

Informações sobre sua configuração n8n

  • Versão n8n:
  • Banco de dados (padrão: SQLite):
  • Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
  • Rodando n8n via (Docker, npm, n8n cloud, aplicativo desktop):
  • Sistema operacional:
3

Oi @Roseline Você está esbarrando em um problema clássico de rate limit e sua configuração atual (retentativas por workflow) sempre causará picos. Cada workflow age independentemente, então retentativas acontecem ao mesmo tempo → tempestades 429.

Tente Centralizar as chamadas de API

Em vez de deixar cada workflow acessar a API:

Todos os workflows → Fila → Worker único → HTTP Request → Processar

Você pode Criar um workflow “API worker”
• Outros workflows enviam requisições para ele (Webhook / Execute Workflow)
• Worker processa requisições uma por uma ou em lotes controlados

Ou use Use Redis / sistema de fila
• Empurre jobs para a fila
• Worker puxa em uma taxa fixa (ex: 100/min)

4

Obrigado pelas sugestões, consigo ver que é um limite de taxa global

5

Obrigado pelas sugestões @Niffzy

6

A abordagem de fluxo centralizado é definitivamente a solução mais limpa. Uma coisa que vale a pena adicionar sobre esse padrão: use um nó Wait com um atraso calculado em vez de um fixo.

Se sua API permite 100 req/min, você pode calcular o atraso por requisição como (60 / 100) * 1000 = 600ms. Então cada chamada para o despachador central apenas espera 600ms antes de passar. Sem “thundering herd”, sem estado Redis compartilhado necessário, e a taxa de transferência permanece previsível.

Para ainda mais resiliência, você também pode adicionar o padrão “circuit breaker” - se receber 3 429s consecutivos, pare de enviar por 60s completos antes de retomar. Isso protege você durante qualquer pico inesperado.

Espero ter ajudado!

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