Tarefas em segundo plano explicadas: como o teu SaaS envia 1.000 emails ou gera um relatório em PDF sem bloquear o ecrã — filas, novas tentativas e dead letter queues.
Uma tarefa em segundo plano (background job) é trabalho que a tua aplicação faz depois de responder ao utilizador: a aplicação aceita a tarefa, responde de imediato e um worker separado termina a parte lenta nos bastidores. Enviar 1.000 emails demora cerca de cinco minutos. Nenhum utilizador vai ficar a olhar para um ecrã bloqueado durante cinco minutos — por isso os produtos em produção nunca lhe pedem isso.
Se o teu SaaS alguma vez vai enviar emails em massa, gerar um relatório ou processar um carregamento de ficheiros, precisas deste conceito. Eis o que é, o que deve ir para uma fila e os erros que fazem os teus utilizadores receber cinco cópias do mesmo email.
O que é uma tarefa em segundo plano, em linguagem simples?
Pensa num café movimentado. Fazes o pedido ao balcão, pagas, recebes um número e sentas-te. A cozinha trata dos pedidos por ordem, e o teu chega quando estiver pronto. Ninguém fica parado à caixa a bloquear a fila até a sua tosta estar feita.
Sem tarefas em segundo plano, é exatamente isso que a tua aplicação faz. Um utilizador clica em "enviar campanha" e a aplicação arrasta-se por 1.000 emails enquanto o ecrã fica bloqueado — durante cinco minutos inteiros. Com tarefas em segundo plano, o clique apenas acrescenta a tarefa a uma fila e responde de imediato "campanha em fila, será enviada em breve". Um worker — um processo separado cujo único trabalho é despachar a fila — envia os emails, repete as falhas e reporta o progresso.
O que deve ir para uma fila — e o que não deve
A regra de ouro: tudo o que demore mais do que um piscar de olhos vai para segundo plano.
| Tarefa | Porque é que o utilizador não pode esperar por ela |
|---|---|
| Enviar uma campanha de email | 1.000 emails demoram cerca de 5 minutos |
| Gerar um relatório em PDF | Demora cerca de 30 segundos |
| Processar o carregamento de um vídeo | Demora cerca de 10 minutos |
| Um resumo diário às 9h | Ninguém está a clicar num botão às 9h — é agendado |
| Entregar dados a outro serviço | O outro serviço pode estar em baixo; a tarefa tenta de novo mais tarde |
E o que não deve ir para lá: tudo o que o utilizador espera que seja instantâneo. Carregar uma página, guardar um formulário, iniciar sessão, receber um pagamento — isto tem de acontecer no momento. Pô-lo em fila acrescenta atraso sem qualquer benefício. É o mesmo padrão que a Stripe usa para gerar faturas e recibos por email, que o GitHub usa nas suas pipelines de build e que o Zapier usa em cada automação que corre.
Novas tentativas, backoff e a dead letter queue
Eis a verdadeira razão pela qual as tarefas em segundo plano importam: o tratamento de falhas. As tarefas falham constantemente em produção — o fornecedor de email tem um soluço, uma API de que dependes vai abaixo, um servidor reinicia a meio de uma tarefa. Um bom sistema de tarefas tenta de novo automaticamente, com intervalos crescentes entre tentativas: um minuto, depois cinco, depois quinze, depois sessenta.
Esses intervalos crescentes — o "exponential backoff" — importam mais do que parece. Se um serviço externo vai abaixo e as tuas tarefas tentam de novo a cada minuto durante horas, estás a martelar um servidor morto, e podes ver os teus endereços bloqueados por isso. Recuar com educação é a forma de os sistemas falharem com elegância.
E quando uma tarefa já falhou vezes demais? Não tenta para sempre. Passa para a dead letter queue — um parque de estacionamento para tarefas que precisam de uma decisão humana. Revês essas tarefas, corriges o problema de fundo e voltas a corrê-las com um clique. Cada tarefa vive algures num único percurso: pendente, em processamento, concluída — ou falhada, a tentar de novo e, por fim, enviada para a dead letter queue.
Os erros que enviam cinco cópias do mesmo email
As tarefas em segundo plano são um padrão resolvido, mas quatro erros clássicos continuam a morder os fundadores que deixam a IA construir o sistema sem saberem o que verificar:
- Tarefas que não são seguras de repetir. Uma tarefa envia um email e depois falha antes de registar que terminou. A nova tentativa corre — e envia o email outra vez. O utilizador recebe cinco cópias da mesma mensagem. Solução: antes de fazer o trabalho, a tarefa verifica "já fiz isto?". Os engenheiros chamam-lhe idempotência; tu podes chamar-lhe a regra do sem duplicados.
- Uma tarefa por email. Uma campanha para 10.000 utilizadores criada como 10.000 tarefas separadas inunda a fila e deixa a base de dados inteira a arrastar-se. Agrupa em vez disso: uma tarefa por cada 100 destinatários transforma 10.000 tarefas em 100.
- Sem limite de trabalho em simultâneo. Cinquenta tarefas de processamento de vídeo a correr ao mesmo tempo esgotam a máquina e deitam o servidor abaixo. Cada fila precisa de um limite para quantas tarefas correm ao mesmo tempo.
- Tarefas presas no limbo. O servidor reinicia a meio de uma tarefa e a tarefa fica marcada como "em processamento" para sempre — nenhum worker lhe volta a tocar. Solução: os workers enviam um sinal de vida a cada 30 segundos; qualquer tarefa sem pulso durante 2 minutos volta para a fila.
Tarefas agendadas: a outra metade
Algum trabalho nem sequer é desencadeado por um utilizador — é desencadeado pelo relógio. O resumo diário às 9h. O relatório semanal. A faturação mensal. A limpeza de dados antigos. São tarefas agendadas: defines o horário uma vez e o sistema de tarefas corre-as automaticamente, com a mesma rede de segurança de novas tentativas que tudo o resto. Se o resumo das 9h falhar, tenta de novo — não descobres uma semana depois que nada foi enviado.
Precisas disto para o teu MVP?
Se o teu MVP só faz coisas instantâneas — formulários, páginas, pagamentos — deixa isto para depois. Mas no momento em que acrescentas a primeira campanha de email, exportação ou processamento de carregamentos, as tarefas em segundo plano deixam de ser opcionais. São um dos 18 sistemas de que qualquer SaaS acaba por precisar, e quase metade dos outros apoia-se neste: o email, as notificações e os relatórios põem todos o seu trabalho pesado em fila aqui.
Mais duas coisas. Primeiro, uma fila para dentro da qual não consegues ver é uma fila a arder em silêncio — junta-lhe uma monitorização para a qual vais mesmo olhar, para saberes quando a dead letter queue começa a encher. Segundo, isto constrói-se muito bem 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 teu trabalho é testar os caminhos de falha, porque os caminhos de falha são o produto.
Perguntas frequentes
O que é uma tarefa em segundo plano, em termos simples?
É trabalho que a tua aplicação faz depois de responder ao utilizador. Em vez de obrigar alguém a ver um ecrã bloqueado enquanto saem 1.000 emails, a aplicação põe a tarefa em fila, responde de imediato e um worker separado faz a parte lenta — com novas tentativas automáticas se alguma coisa falhar.
O que acontece quando uma tarefa em segundo plano falha?
Tenta de novo automaticamente, com intervalos crescentes entre tentativas — um minuto, depois cinco, depois quinze, depois sessenta — para não martelar um serviço que já está com dificuldades. Se continuar a falhar depois do número máximo de tentativas, passa para a dead letter queue, onde a revês e a voltas a correr depois de o problema de fundo estar resolvido.
O que é uma dead letter queue?
Uma área de espera para tarefas que falharam todas as tentativas. Nada se perde e nada fica a tentar inutilmente para sempre — a tarefa espera ali, com todo o seu histórico, até que um humano decida o que fazer. Uma dead letter queue vazia é um dos sinais mais saudáveis que o teu produto te pode mostrar.
Preciso de tarefas em segundo plano para o meu MVP?
Só quando fizeres alguma coisa lenta. 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 início de sessão, nunca devem ser postas em fila. Acrescenta tarefas quando acrescentares a primeira funcionalidade de email em massa, de relatórios ou de processamento de ficheiros.