Melhores Práticas de Filas

Monitore a profundidade da fila; alerte antes que os consumidores se afoguem. Filas desacoplam HTTP de trabalho lento apenas quando a disciplina de operações corresponde.

Como Usar Esta Lista

• Monitore contagens de espera/ativas/falhadas por fila no dashboard antes do lançamento
• Teste de carga para rajadas do produtor com contagem fixa de workers
• Emparelhe com Chaves de Idempotência para fluxos de pagamento
• Execute um teste trimestral de redrive da DLQ

A - Regras do Produtor (API)

• HTTP retorna 202 com ID do job para trabalho com duração esperada >500ms.
• Enqueue é rápido - sem serialização pesada ou trabalho de DB no caminho do enqueue.
• ID do job / chave de idempotência estável em mutações retentadas pelo cliente.
• ID de correlação no payload do job para rastreamento entre logs da API e do worker.
• Filas separadas por domínio e raio de explosão (email, billing, media).

B - Regras do Worker

• Workers idempotentes - seguros se o job for executado duas vezes (entrega parada do SQS/BullMQ).
• Concorrência ajustada por tipo de job - perfis de I/O vs CPU bound diferem.
• Lance erros transitórios para acionar retentativa; capture erros permanentes para falhar rapidamente.
• Efeitos colaterais após verificação de idempotência local e commit no DB.
• Atualizações de progresso para jobs com espera visível ao usuário >30s.

C - Retentativas e DLQ

• Backoff exponencial em chamadas de fornecedor de saída dentro dos jobs.
• Máximo de tentativas limitado (3-10 dependendo do custo).
• DLQ configurada (redrive SQS ou conjunto falhado do Bull) com alarme.
• Runbook: inspecionar DLQ, corrigir, redrive documentado na wiki de plantão.
• Identificação de mensagem venenosa - registre o nome do job + hash do payload, não segredos.

D - Operações

• Métricas: profundidade, idade da mensagem mais antiga, taxa de processamento, taxa de falha.
• Workers escalam automaticamente com base na profundidade (métrica customizada HPA do k8s ou escalonamento em etapas do ECS).
• Desligamento gracioso - worker.close() com período de graça > tempo do job p99.
• Memória do Redis/ElastiCache monitorada ao usar BullMQ.
• Tempo limite de visibilidade / lockDuration > duração do handler p99.

E - Payload e Segurança

• Payload < 64KB idealmente; referência S3 para arquivos grandes.
• Sem PII bruta, a menos que necessário - passe IDs e carregue no worker.
• Privilégio mínimo do IAM do worker para S3, SQS, Stripe, etc.
• Criptografe campos sensíveis do job se a fila for acessível por admin multi-tenant.
• UI de retentativa de admin (Bull Board) atrás de autenticação e log de auditoria.

F - Agendamento

• Sem cron duplicado entre réplicas sem lock ou CronJob do k8s.
• Jobs repetíveis do BullMQ usam jobId estável.
• Política de execução perdida documentada (catch-up vs skip).
• Agendamentos pesados enfileiram jobs de worker em vez de executar inline na API.
• Fuso horário UTC explícito nas definições de cron.

FAQs

Relacionado

• Fundamentos de Filas - fundamentos
• BullMQ - filas Redis
• Consumidores AWS SQS - filas gerenciadas
• Chaves de Idempotência - segurança contra duplicatas
• Desligamento Gracioso - dreno do worker

Versões da Stack: Esta página foi escrita para Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5, e NestJS 11.