Você aprendeu a construir um hosted service. Agora vem a pergunta que ninguém respondeu: onde ele deve rodar? Dentro da sua API ASP.NET Core, ou em um worker service separado? Escolher errado aqui custa caro — ou você degrada o desempenho dos seus endpoints, ou adiciona complexidade de infraestrutura sem necessidade.
Ao final deste post você vai ter um critério claro para decidir, caso a caso, onde colocar seu processamento em background.
O mesmo código roda nos dois lugares
Antes da decisão, um fato que dá liberdade: o mesmo BackgroundService e o mesmo AddHostedService<T>() funcionam tanto em um Worker Service quanto em uma API ASP.NET Core.
// funciona idêntico na API e no worker service
builder.Services.AddHostedService<JobProcessor>();
Ou seja, a decisão não é técnica de implementação — é uma decisão de arquitetura. Você não está escolhendo APIs diferentes; está escolhendo onde sua carga de trabalho vive e como ela escala.
Quando o hosted service na API é a escolha certa
Hosted services dentro da própria aplicação brilham para trabalho leve em background que pertence à aplicação em si. Alguns exemplos tÃpicos:
- Atualizar dados em cache periodicamente.
- Fazer polling de pequenos datasets.
- Executar tarefas de manutenção rotineiras.
O fio condutor: essas tarefas são estreitamente acopladas à aplicação e não precisam de escalabilidade independente. Elas vivem e morrem com a API, e está tudo bem assim. Colocá-las num serviço separado só adicionaria partes móveis sem benefÃcio.
Quando mover para um worker service dedicado
Do outro lado estão as cargas mais pesadas. Para trabalho de longa duração ou intensivo em recursos, frequentemente a melhor abordagem é mover esse processamento para um worker service separado.
O benefÃcio central é duplo:
- A carga de trabalho em background pode escalar de forma independente.
- Você evita impactar o desempenho da sua API — o background pesado não disputa recursos com quem está atendendo requisições.
Se o seu job consome muita CPU/memória ou roda por muito tempo, mantê-lo dentro da API significa que cada pico de processamento pode degradar a latência dos seus endpoints. Separar resolve isso.
A regra prática
Dá para resumir a decisão em uma regra simples:
- Tarefa leve e estreitamente acoplada à aplicação? → um hosted service dentro da API é mais apropriado.
- Tarefa de longa duração, intensiva em recursos ou que precisa de escalabilidade própria? → mova para um worker service dedicado.
Comece simples. Se o trabalho é leve e nasce junto com a API, não há motivo para criar um serviço separado só por purismo. Mas no momento em que ele começa a pesar, a durar ou a exigir escala própria, esse é o sinal de que chegou a hora de tirá-lo de dentro da API.
Conclusão
A escolha entre hosted service na API e worker service dedicado não é sobre código — é sobre acoplamento e escala. Trabalho leve e acoplado fica na API; trabalho pesado, longo ou que precisa escalar sozinho vai para um worker dedicado. Entender quando usar cada um é o que separa um sistema que aguenta produção de um que trava sob carga.
Olhe para os hosted services que você tem hoje: algum deles está pesando dentro da sua API e merecia virar um worker próprio? Esse é o próximo passo natural — e é exatamente o que construiremos a seguir: um worker service dedicado para processar jobs fora da aplicação web.
