Background jobs explicados: como seu SaaS envia 1.000 e-mails ou gera um relatório em PDF sem travar a tela — filas, novas tentativas e dead letter queue.
Um background job é um trabalho que o seu app faz depois de responder ao usuário: o app aceita a tarefa, responde na hora, e um worker separado termina a parte lenta nos bastidores. Enviar 1.000 e-mails leva cerca de cinco minutos. Nenhum usuário vai ficar olhando para uma tela travada por cinco minutos — por isso, produtos em produção nunca pedem isso a ele.
Se o seu SaaS algum dia for enviar e-mails em massa, gerar um relatório ou processar um upload, você precisa desse conceito. Aqui está o que ele é, o que vai para uma fila e os erros que fazem seus usuários receberem cinco cópias do mesmo e-mail.
O que é um background job, em linguagem simples?
Pense numa cafeteria movimentada. Você faz o pedido no balcão, paga, recebe uma senha e se senta. A cozinha vai preparando os pedidos em sequência, e o seu chega quando fica pronto. Ninguém fica parado no caixa, travando a fila, até o sanduíche sair da chapa.
Sem background jobs, é exatamente isso que o seu app faz. Um usuário clica em "enviar campanha" e o app vai processando 1.000 e-mails enquanto a tela congela — por cinco minutos inteiros. Com background jobs, o clique só adiciona a tarefa a uma fila e responde na hora: "campanha na fila, será enviada em breve". Um worker — um processo separado cujo único trabalho é ir esvaziando a fila — envia os e-mails, tenta de novo os que falharam e informa o progresso.
O que vai para uma fila — e o que não vai
A regra prática: qualquer coisa mais lenta que um piscar de olhos vai para segundo plano.
| Tarefa | Por que o usuário não pode esperar por ela |
|---|---|
| Enviar uma campanha de e-mail | 1.000 e-mails levam cerca de 5 minutos |
| Gerar um relatório em PDF | Leva cerca de 30 segundos |
| Processar o upload de um vídeo | Leva cerca de 10 minutos |
| Um resumo diário às 9h | Ninguém está clicando num botão às 9h — é agendado |
| Entregar dados para outro serviço | O outro serviço pode estar fora do ar; o job tenta de novo depois |
E o que não vai para lá: qualquer coisa que o usuário espera que aconteça na hora. Carregar uma página, salvar um formulário, fazer login, receber um pagamento — isso tem que acontecer no momento. Colocar na fila só adiciona atraso sem benefício nenhum. É o mesmo padrão que a Stripe usa para gerar faturas e recibos por e-mail, que o GitHub usa nos seus pipelines de build e que o Zapier usa em cada automação que roda.
Novas tentativas, backoff e a dead letter queue
Este é o motivo real pelo qual background jobs importam: tratamento de falhas. Jobs falham o tempo todo em produção — o provedor de e-mail dá uma engasgada, uma API da qual você depende sai do ar, um servidor reinicia no meio da tarefa. Um bom sistema de jobs tenta de novo automaticamente, com intervalos crescentes entre as tentativas: um minuto, depois cinco, depois quinze, depois sessenta.
Esses intervalos crescentes — o "exponential backoff" — importam mais do que parece. Se um serviço de terceiros sai do ar e os seus jobs tentam de novo a cada minuto durante horas, você está martelando um servidor morto, e pode ter os seus endereços bloqueados por isso. Recuar com educação é como os sistemas falham com elegância.
E quando um job já falhou vezes demais? Ele não fica tentando para sempre. Ele vai para a dead letter queue — um estacionamento para jobs que precisam de uma decisão humana. Você os revisa, corrige o problema de fundo e roda de novo com um clique. Todo job está em algum ponto de um único caminho: pendente, processando, concluído — ou falhou, tentando de novo e, por fim, na dead letter queue.
Os erros que enviam cinco cópias do mesmo e-mail
Background jobs são um padrão resolvido, mas quatro erros clássicos continuam mordendo fundadores que deixam a IA construir o sistema sem saber o que verificar:
- Jobs que não são seguros para repetir. Um job envia um e-mail e trava antes de registrar que terminou. A nova tentativa roda — e envia o e-mail de novo. O usuário recebe cinco cópias da mesma mensagem. Solução: antes de fazer o trabalho, o job verifica "eu já fiz isso?". Engenheiros chamam isso de idempotência; você pode chamar de regra do sem-duplicatas.
- Um job por e-mail. Uma campanha para 10.000 usuários criada como 10.000 jobs separados inunda a fila e deixa o banco de dados inteiro se arrastando. Agrupe: um job a cada 100 destinatários transforma 10.000 jobs em 100.
- Sem limite de trabalho simultâneo. Cinquenta jobs de processamento de vídeo rodando ao mesmo tempo esgotam a máquina e derrubam o servidor. Cada fila precisa de um teto de quantos jobs rodam ao mesmo tempo.
- Jobs presos no limbo. O servidor reinicia no meio do job e ele fica marcado como "processando" para sempre — nenhum worker vai tocar nele de novo. Solução: os workers enviam um sinal de vida a cada 30 segundos; qualquer job sem pulso por 2 minutos volta para a fila.
Tarefas agendadas: a outra metade
Alguns trabalhos não são disparados por um usuário — são disparados pelo relógio. O resumo diário às 9h. O relatório semanal. A cobrança mensal. A limpeza de dados antigos. São tarefas agendadas: você define o cronograma uma vez e o sistema de jobs as executa automaticamente, com a mesma rede de segurança de novas tentativas que todo o resto. Se o resumo das 9h falhar, ele tenta de novo — você não descobre uma semana depois que nada foi enviado.
Você precisa disso no seu MVP?
Se o seu MVP só faz coisas instantâneas — formulários, páginas, pagamentos —, deixe para depois. Mas, no momento em que você adicionar a primeira campanha de e-mail, exportação ou processamento de upload, background jobs deixam de ser opcionais. Eles são um dos 18 sistemas de que todo SaaS acaba precisando, e quase metade dos outros se apoia neste: e-mail, notificações e relatórios, todos colocam o trabalho pesado na fila aqui.
Mais duas coisas. Primeiro, uma fila que você não consegue enxergar por dentro é uma fila pegando fogo em silêncio — combine-a com um monitoramento que você vai de fato olhar, para saber quando a dead letter queue começar a encher. Segundo, isso é bem construível com IA: a partir de uma especificação completa, o sistema inteiro — filas, novas tentativas, o agendador, o painel — leva cerca de 3–4 horas com o Claude. O seu trabalho é testar os caminhos de falha, porque os caminhos de falha são o produto.
Perguntas frequentes
O que é um background job, em termos simples?
É um trabalho que o seu app faz depois de responder ao usuário. Em vez de fazer alguém olhar para uma tela travada enquanto 1.000 e-mails são enviados, o app coloca a tarefa na fila, responde na hora, e um worker separado faz a parte lenta — com novas tentativas automáticas se algo falhar.
O que acontece quando um background job falha?
Ele tenta de novo automaticamente, com intervalos crescentes entre as tentativas — um minuto, depois cinco, depois quinze, depois sessenta —, para não martelar um serviço que já está com problemas. Se ainda falhar depois do número máximo de tentativas, vai para a dead letter queue, onde você o revisa e o roda de novo depois de corrigir o problema de fundo.
O que é uma dead letter queue?
Uma área de espera para jobs que falharam em todas as tentativas. Nada se perde e nada fica tentando de novo à toa para sempre — o job espera ali, com todo o histórico, até um humano decidir o que fazer. Uma dead letter queue vazia é um dos sinais mais saudáveis que o seu produto pode te mostrar.
Preciso de background jobs no meu MVP?
Só quando você fizer algo lento. Consultas simples e ações instantâneas não precisam de fila — o custo extra não compensa, e operações críticas em tempo real, como pagamentos e login, nunca devem ir para a fila. Adicione jobs quando adicionar sua primeira funcionalidade de e-mail em massa, relatório ou processamento de arquivos.