- Fila separa “receber” de “processar” e evita efeito dominó quando APIs ficam lentas
- Retry sem backoff vira ataque acidental ao fornecedor e piora o rate limit
- Idempotência é a diferença entre “repetir com segurança” e “duplicar pedido/cobrança”
- DLQ (dead-letter queue) transforma erro em tarefa de reprocessamento, não em incêndio
- Observabilidade mínima: log estruturado + correlação por ID + alerta por taxa de falha
1) Defina o “evento” e o contrato de entrada
Escreva qual evento dispara o fluxo (ex.: PedidoPago, LeadCriado, MensagemRecebida) e quais campos são obrigatórios. Valide na borda: se faltou ID do pedido, não “tenta assim mesmo”. Se vier duplicado, reconheça e descarte com base em uma chave única. Resultado esperado: você consegue responder rápido ao webhook e não depende do resto do fluxo para aceitar o evento.
2) Separe ingestão de processamento (e coloque uma fila no meio)
Padrão que reduz dor: Webhook → validação → enfileira (payload + idempotency key) → worker processa. A fila pode ser um serviço dedicado (RabbitMQ/SQS etc.) ou uma tabela/coleção com status (quando você não tem fila de verdade). O importante é existir um buffer e um estado: RECEBIDO, PROCESSANDO, CONCLUÍDO, FALHOU.
3) Faça retry do jeito certo: categorias de erro + backoff + limite
Nem todo erro merece retry. Regras práticas: (a) 429/rate limit e 5xx geralmente merecem retentar com backoff exponencial e jitter; (b) 4xx por validação (ex.: campo inválido) quase nunca resolve com retry; (c) timeouts podem ser intermitentes, mas precisam de teto. Coloque número máximo de tentativas e um tempo máximo total (para não virar loop).
4) Aplique idempotência nos pontos que geram efeito
Onde há efeito real (criar pedido, emitir nota, cobrar Pix, mandar WhatsApp, criar ticket), crie um mecanismo de “executa no máximo uma vez”. Use uma chave de idempotência derivada do evento (ex.: source=shopify + order_id + action=capture) e registre o resultado. Se o mesmo evento voltar, você retorna o resultado anterior em vez de repetir a ação.
5) Crie uma DLQ e um rito de reprocessamento
DLQ é a ‘caixa de falhas’ com contexto. Quando estourar o limite de retry, mande o job para DLQ com: payload original, erro, tentativas, timestamps e link para logs. Reprocessar precisa ser explícito (manual ou agendado), com trilha de auditoria e sem perder a idempotência.
6) Adicione observabilidade mínima (para não depender de “print”)
Guarde um correlation_id por execução (idealmente o ID do evento). Logue início/fim, tempo gasto, etapa onde falhou e resposta da API (sem vazar dado sensível). Crie alertas por: taxa de falha, tamanho da fila, crescimento da DLQ e picos de 429. Sem isso, você só descobre quando o cliente reclama.
O desenho mental que evita 80% das quebras
Quando uma automação dá errado, quase sempre é por um destes motivos: (1) você depende do tempo real de APIs instáveis; (2) você repete ações sem controle; (3) você não tem “estado” para saber o que já aconteceu; (4) você não enxerga o erro antes do usuário.
A arquitetura mais “pé no chão” para automação é: receber rápido, processar com calma, escrever com segurança. Isso vale para n8n, Make, Zapier ou código puro — muda a implementação, não o princípio.
- Entrada: webhook/polling + validação + autenticação
- Meio: fila (buffer) + workers (processamento)
- Saída: ações idempotentes + auditoria + notificações
Fila: quando usar e quando é excesso
Fila não é luxo; é isolamento. Se o seu fluxo faz chamadas externas (pagamentos, marketplaces, WhatsApp, ERPs), você está a uma instabilidade de distância de travar tudo.
Agora, se a automação é interna, rápida e sem efeito financeiro (ex.: copiar linha para planilha), a fila pode ser mais complexidade do que benefício. O gatilho aqui é: existe risco de burst (picos) e existe custo de duplicar?
| Sinal | Sem fila costuma dar ruim | Com fila melhora porque... |
|---|---|---|
| Picos de eventos (campanha, marketplace, black friday) | Execuções acumulam, timeouts e efeito cascata | O buffer absorve o pico e os workers escoam no ritmo seguro |
| API externa com rate limit | Você bate 429 e entra em retry caótico | Você controla concorrência e espaçamento entre tentativas |
| Ação com dinheiro/estoque | Duplicidade vira prejuízo | Você impõe idempotência e reprocessa sem repetir efeito |
| Fluxos longos (muitos passos) | Uma falha no final refaz tudo | Você checkpointa e retoma do ponto certo |
Retry e backoff: o que fazer com 429, 5xx e timeout
Retry é obrigatório, mas precisa de disciplina. O erro clássico: retentar imediatamente, em paralelo, sem limite. Isso transforma instabilidade pequena em indisponibilidade total.
Uma regra simples que funciona bem: backoff exponencial com jitter (um ‘ruído’ aleatório) e teto de tentativas. Se a automação não pode atrasar, você decide pelo fallback (ex.: notificar humano) em vez de insistir para sempre.
| Tipo de erro | Exemplo | Tratamento recomendado |
|---|---|---|
| Rate limit | HTTP 429 | Retry com backoff + jitter; reduza concorrência; respeite cabeçalhos de limite quando existirem |
| Falha temporária do fornecedor | HTTP 500/502/503 | Retry com backoff; se persistir, envia para DLQ e alerta |
| Timeout/rede | Sem resposta / conexão caiu | Retry limitado; antes, torne a ação idempotente para evitar duplicar |
| Erro de regra/validação | HTTP 400, payload inválido | Não retentar automaticamente; corrigir dados e reprocessar após ajuste |
Idempotência na prática: como não duplicar pedidos, mensagens e cobranças
Idempotência parece teórica até o dia em que o webhook dispara duas vezes (e ele dispara). Pode ser reenvio do fornecedor, timeout do seu lado, clique duplicado, ou reprocessamento manual.
O jeito prático: escolha uma chave estável por evento e por ação. Se a ação já foi executada com aquela chave, você retorna o mesmo resultado e não repete. Isso vale para enviar WhatsApp, criar lead, emitir nota, registrar pagamento.
- Exemplo de idempotency key: "shopify:order:12345:capture"
- Armazene: key, status, resultado (IDs gerados), timestamps, última mensagem de erro
- Antes de executar: consulte a key; se CONCLUÍDO, pare; se PROCESSANDO, evite corrida; se FALHOU, decida reprocessar
DLQ (Dead-Letter Queue): onde o erro vai parar para virar trabalho, não caos
DLQ é o lugar para as falhas que não vão se resolver com mais uma tentativa. Sem DLQ, você só tem duas opções ruins: perder o evento ou ficar retentando para sempre.
DLQ bem feita tem contexto suficiente para reprocessar com segurança: payload original, motivo, quantas tentativas, e qual idempotency key está associada. O reprocessamento pode ser manual (com critério) ou automatizado (com janela e limites).
Checklist rápido antes de colocar em produção
Se você fizer só isso, já evita a maioria das tragédias silenciosas.
- Tenho um ID único do evento (ou consigo criar um)?
- Consigo responder rápido ao webhook e processar depois?
- Retry tem limite, backoff e tratamento diferente para 400 vs 429 vs 5xx?
- Ações com efeito (dinheiro/estoque/mensagem) são idempotentes?
- Falhas finais vão para DLQ com contexto para reprocessar?
- Tenho logs com correlation_id e alerta de falha/tamanho de fila?
Perguntas frequentes
Preciso mesmo de fila se eu uso n8n/Make/Zapier?
Como escolher o número de tentativas de retry e o tempo de backoff?
Idempotência é só para webhooks?
O que eu registro no log sem ferir LGPD?
Leia também
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 fazer idempotência em automações com webhook (e parar de duplicar pedidos, notas e leads)
Guia direto para aplicar idempotência em automações com webhook: chaves idempotentes, deduplicação, banco/planilha, retries e boas práticas para n8n/Make/Zapier.
Ler →
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 →