O que é um worker e por que os aplicativos usam tarefas em segundo plano?

Publicado em 2026-10-20 por frfrand

Workers explicados con ejemplos: colas, Celery, correos, PDFs, trabajos demorados, reintentos e idempotencia sin bloquear una web.

Um worker é um processo que se encarrega de executar tarefas fora do fluxo principal de uma aplicação. No desenvolvimento web, costuma-se usar para trabalhos que demoram demais para manter uma pessoa esperando em frente a uma página: gerar arquivos, processar imagens, enviar notificações ou importar milhares de registros.

Não significa que o trabalho desapareça. Simplesmente é executado em outro processo, e muitas vezes em outra máquina.

O exemplo do restaurante

Imagine um restaurante em quem pede o pedido também deve preparar cada prato antes de atender ao próximo cliente. Seria um desastre: todos terminariam fazendo fila, mesmo que quisessem apenas perguntar pelo cardápio.

Em uma aplicação ocorre algo parecido quando uma solicitação HTTP deve esperar que termine uma operação pesada. O habitual é receber a solicitação, registrar o que há para fazer e delegar a tarefa.

Então entra em cena o worker.

Qual a diferença entre a web, uma fila e um worker?

A aplicação web atende requisições. A fila mantém informações sobre os trabalhos pendentes. O worker obtém trabalhos e executa a lógica correspondente.

Por exemplo, um cliente clica em «gerar relatório». A web pode criar uma tarefa e devolver um identificador em poucos segundos. O worker a processa e, ao terminar, o usuário recebe um aviso ou pode baixar o arquivo.

De acordo com a tecnologia escolhida, a fila e a execução podem ser coordenadas com Redis, RabbitMQ ou outros sistemas. Cada combinação oferece diferentes garantias.

Um caso prático: envio de e-mails

Se um novo usuário for registrado, o aplicativo pode confirmar o registro e enviar um e-mail de boas-vindas como uma tarefa secundária.

Mas cuidado: se o e-mail não chegar, o que deve acontecer? É reenviado? Quantas vezes? E se o provedor de e-mail recebeu a mensagem, mas o worker perdeu a confirmação?

Essas perguntas importam porque uma tarefa executada duas vezes pode causar efeitos duplicados. Enviar dois e-mails pode ser irritante; cobrar duas vezes uma compra seria muito pior.

O que significa idempotência?

Uma operação é idempotente quando repeti-la produz o mesmo efeito relevante que executá-la uma vez. Por exemplo, definir o status de um pedido como «processado» pode ser projetado para tolerar repetições.

Por outro lado, «somar 10 € ao saldo» não é idempotente se cada execução somar outros 10 €. Quando as filas podem repetir tarefas, esse detalhe deixa de ser teoria.

Uma prática comum é utilizar identificadores únicos para não reaplicar o mesmo efeito se ele já foi realizado.

O que acontece se o worker for desligado?

Depende de como as mensagens e as confirmações são gerenciadas. Algumas configurações reconhecem uma tarefa antes de executá-la; outras podem devolvê-la à fila após uma interrupção.

Não existe uma garantia universal de «execução exatamente uma vez» por instalar o Celery ou o Redis. É preciso compreender as retentativas, as confirmações, os tempos máximos e como registrar os resultados.

O que é o Celery?

O Celery é uma ferramenta conhecida do ecossistema Python para definir e executar tarefas distribuídas por meio de workers e um sistema de mensageria. É frequentemente usado com o Django, embora não esteja limitado a esse framework.

Você pode definir uma tarefa que processe um relatório e enviá-la à fila a partir do backend. Os workers executam essa função quando têm capacidade disponível.

Para operar corretamente, é necessário ter supervisão, registro de erros e configuração adequada da concorrência.

Mais workers significa mais velocidade?

Nem sempre. Se todas as tarefas competirem pelo mesmo banco de dados ou consumirem toda a memória disponível, adicionar workers pode piorar a situação.

Há trabalhos limitados por CPU, outros por rede e outros por serviços externos. Antes de aumentar os processos, convém medir quanto tempo cada tarefa leva e onde está o gargalo.

Também é importante limitar as retentativas: se um provedor externo falhar, não faz sentido lançar milhares de tentativas por segundo e agravar o problema.

Quando você não precisa de um worker?

Se uma operação terminar em milissegundos e fizer parte da resposta imediata, introduzir uma fila pode adicionar complexidade desnecessária.

O objetivo não é criar uma arquitetura maior, mas manter o aplicativo disponível quando surgem tarefas prolongadas ou imprevisíveis.

E no ArduMaker?

No ArduMaker, é possível gerenciar aplicações e serviços que utilizam Redis e workers dentro de VPS. Em sistemas com n8n e outros processos em segundo plano, também é importante separar o componente que recebe requisições do que executa trabalhos demorados.

Em resumo: um worker executa tarefas que não deveriam bloquear a resposta principal. Uma fila ajuda a coordená-las, mas a confiabilidade depende de como você projeta retentativas, erros e operações duplicadas.

Fontes: Guia de tarefas do Celery · Introdução aos workers do Celery.