- Concorrência (paralelo) é diferente de volume (total de requisições no dia); APIs punem os dois jeitos
- O erro 429 quase sempre pede: menos chamadas por janela + retry com backoff + jitter
- Lotes pequenos e constantes costumam ser mais estáveis do que “explodir” em paralelo
- Desacoplar com filas evita que um pico de entrada vire pico de saída
- Idempotência é o cinto de segurança: retry sem duplicar cobrança, mensagem ou pedido
1) Descubra onde a concorrência está nascendo (e não chute)
Abra o workflow e marque os pontos onde há: (a) Split in Batches/loops, (b) múltiplos ramos executando ao mesmo tempo, (c) várias execuções simultâneas via Webhook/Triggers. A pergunta simples é: “quantas requisições podem sair ao mesmo tempo daqui?”. Se você não consegue responder, você ainda não está pronto para otimizar.
2) Troque paralelismo por lotes controlados
Quando você recebe muitos itens (linhas do Sheets, pedidos, contatos), prefira processar em lotes pequenos com Split in Batches. Entre lotes, insira uma espera curta (Wait/Delay) para suavizar a curva. Isso é mais previsível do que disparar 300 requisições de uma vez e torcer para a API aceitar.
3) Padronize tratamento de 429 e 5xx (retry com backoff)
Se a API responde 429 (rate limit) ou 5xx (instabilidade), não adianta “só tentar de novo” imediatamente. Configure um caminho de erro: capturar status code, esperar com backoff (ex.: aumentar progressivamente o tempo), adicionar variação (jitter) para não sincronizar várias execuções, e tentar novamente até um limite. Quando exceder, mande para uma DLQ (fila de mortos) ou para uma lista de reprocesso.
4) Desacople picos com fila (quando o fluxo é acionado por eventos)
Se chegam 200 eventos em 1 minuto (webhook, WhatsApp, e-commerce), você não é obrigado a “pagar” isso em chamadas de API no mesmo minuto. Enfileire a entrada e processe com um ou poucos workers. Em n8n, isso normalmente significa rodar em Queue Mode ou usar uma fila externa quando faz sentido. O ganho é estabilidade: entrada pode explodir; saída fica domada.
5) Implemente idempotência antes de aumentar o retry
Retry sem idempotência vira duplicidade. Gere uma idempotency key por ação (ex.: pedidoId+tipoAcao), registre o que já foi feito (banco/planilha/cache) e cheque antes de executar de novo. Assim você pode ser agressivo no retry sem medo de cobrar duas vezes, mandar duas mensagens ou criar dois tickets.
6) Separe “trabalho pesado” do “trabalho rápido”
Trabalho rápido: validar payload, registrar evento, responder webhook. Trabalho pesado: enriquecer dados, chamar IA, consultar várias APIs. Faça o webhook responder rápido e empurre o pesado para um processamento assíncrono (fila/worker). Isso reduz timeouts e diminui a tentação de rodar tudo em paralelo.
7) Monitore e ajuste com base em evidência
Registre: taxa de 429, tempo médio por item, tamanho dos lotes, taxa de reprocesso e gargalos. O ajuste costuma ser iterativo: lote menor, mais espera; ou mais workers, mas com rate limit por worker. Se você só mexe quando quebra, vai viver no modo incêndio.
Concorrência no n8n: o que realmente significa na prática
Quando alguém diz “meu n8n estourou a API”, quase sempre é uma mistura de (1) muitas execuções simultâneas do workflow e (2) muitas requisições por execução, disparadas rápido demais.
Concorrência é o número de coisas acontecendo ao mesmo tempo. Volume é o total de coisas ao longo do tempo. API costuma impor limites por janela (por segundo/minuto) e, em alguns casos, por dia. Seu fluxo pode respeitar o limite diário e ainda assim tomar 429 em picos.
Estratégias rápidas (e quando cada uma faz sentido)
Nem toda automação precisa de fila externa, e nem todo caso se resolve com um simples Wait. A ideia é escolher a menor solução que te dá previsibilidade.
| Problema típico | Sinal | Tática que costuma resolver | Cuidado |
|---|---|---|---|
| 429 (rate limit) intermitente | Falha em horários de pico | Retry com backoff + jitter | Sem idempotência, retry pode duplicar ações |
| Explosão de requisições ao processar lista grande | Execução longa e muitos itens | Split in Batches + Wait entre lotes | Lote grande demais continua causando pico |
| Muitos webhooks simultâneos | Várias execuções sobrepostas | Fila (Queue Mode/externa) + workers controlados | Fila sem DLQ vira buraco negro quando dá erro |
| API lenta derruba o fluxo inteiro | Timeouts e execução travada | Separar “receber evento” de “processar” | Responder webhook tarde demais pode gerar reentrega |
Um desenho de referência (simples) para não viver de 429
Se você quer um padrão que funciona bem em ambiente real (e não só em demo), use este desenho mental: entrada rápida → registro do evento → fila → processamento em batches → chamadas externas com retry/backoff → registro de sucesso → DLQ para falhas definitivas.
Você não precisa implementar tudo de uma vez. Mas quanto mais o seu fluxo encosta em dinheiro, mensagem para cliente ou operação crítica, mais esses blocos deixam de ser “perfeccionismo” e viram “higiene”.
Perguntas frequentes
Como sei se meu problema é concorrência ou limite diário da API?
Colocar Wait resolve 429 sempre?
Vale usar Queue Mode no n8n só para “não estourar API”?
Como evitar duplicar mensagem/cobrança quando há retry?
Leia também
Rate limit, retry e backoff: como parar de quebrar automação em API (n8n, Make, Zapier)
Guia direto para lidar com rate limit (429), retries e backoff em automações com APIs. Aprenda padrões práticos para n8n, Make e Zapier e evite falhas intermitentes, duplicidades e banimentos.
Ler →
n8n vs Make para workflows long-running: filas, retries e tarefas que não podem falhar
Entenda qual ferramenta lida melhor com automações longas (minutos/horas), filas, rate limit e reprocessamento: n8n ou Make. Comparação prática com cenários reais no Brasil.
Ler →
Como usar Dead Letter Queue (DLQ) em automações: trate falhas sem perder eventos
Guia prático de Dead Letter Queue (DLQ) para automações: quando usar, como modelar eventos, reprocessar com segurança e evitar duplicidade em n8n/Make/Zapier.
Ler →
Como desenhar uma arquitetura de automação com filas, retry e idempotência (sem virar gambiarra)
Guia prático para desenhar automações resilientes: quando usar filas, como fazer retry/backoff, idempotência e DLQ. Evite duplicar pedidos, estourar rate limit e cair em loop infinito em n8n/Make/Zapier.
Ler →