Workers consomem de uma fila e executam jobs. Use uma instância pequena dedicada ou rode junto com a app. Escale workers horizontalmente; garanta idempotência e tratamento dead-letter. Monitore profundidade da fila e tempo de processamento.
O que workers fazem
- Consomem: Puxam mensagens de uma fila (Redis list/stream, RabbitMQ, SQS etc.). Cada mensagem dispara um job (ex. enviar e-mail, processar imagem, sincronizar dados).
- Desacoplam: A app enfileira e retorna; workers processam de forma assíncrona. Lida com picos e tarefas longas sem bloquear a camada web.
- Backends: Redis (filas ou streams simples), RabbitMQ (roteamento, DLQ), SQS (gerenciado, em escala). Escolha por latência, durabilidade e preferência de ops.
Opções de implantação
- Instância(s) dedicada(s): VPS pequeno ou container(s) que só rodam workers. Isola CPU/memória da app; mais fácil escalar workers de forma independente.
- Junto com a app: Workers no mesmo servidor que a app. Mais simples para setups pequenos. Risco: jobs pesados podem competir com a app. Use process manager e limites de recurso.
- Serverless: Lambda, Cloud Run ou similar para jobs orientados a eventos. Paga por invocação; sem custo ocioso.
Confiabilidade
- Idempotência: Projete jobs para que rodar duas vezes (ex. retry após timeout) não cause efeitos colaterais duplicados. Use chaves de idempotência ou chaves naturais.
- Dead-letter: Quando um job falhar após N tentativas, mova para uma fila dead-letter (DLQ). Monitore a DLQ; corrija mensagens ruins ou replay após corrigir o bug.
- Visibilidade: Monitore profundidade da fila (backlog), tempo de processamento e taxa de erro. Alerte em backlog crescente ou pico de falhas.
Resumo
Workers consomem de uma fila e executam jobs. Use instância dedicada ou rode junto com a app. Escale horizontalmente; garanta idempotência e dead-letter. Monitore profundidade da fila e tempo de processamento.
