Seu endpoint que sempre respondia em 80ms começou a oscilar para 800ms — e ninguém mexeu no código dele. O culpado? Aquele BackgroundService que você colocou na API mês passado para gerar relatórios. Ele está rodando dentro do mesmo processo que suas requisições, e agora os dois estão brigando pela mesma CPU.

Esse é um dos erros arquiteturais mais silenciosos do .NET: começar com hosted services dentro da API e só descobrir o problema quando a produção já está degradada. Neste post você vai entender quando o background work deve sair da API e por que Worker Services são a resposta — não pela sintaxe, mas pelos trade-offs reais.

O problema: hosted services compartilham tudo com a sua API

Hosted services (IHostedService / BackgroundService) são ótimos para tarefas que pertencem à aplicação e são leves: limpar um cache, emitir um heartbeat, recarregar uma configuração de tempos em tempos.

Mas há uma característica fácil de esquecer: eles rodam dentro do mesmo processo da sua API. Isso significa que compartilham:

• a mesma memória,
• os mesmos recursos de CPU,
• o mesmo ciclo de vida.

Para cargas leves, isso é perfeito. O problema aparece quando o trabalho fica pesado.

Imagine que seu serviço em background está processando arquivos grandes, gerando relatórios ou chamando múltiplos sistemas externos. Se esse trabalho executa dentro do processo da API, ele está competindo com as requisições que chegam pelos mesmos recursos.

O resultado é direto: tempos de resposta mais lentos e performance instável. E o pior tipo de instabilidade — aquela que não aparece no código de nenhum endpoint, só na conta de recursos compartilhada.

A segunda dor: você só consegue escalar tudo junto

Essa é a parte que mais machuca em sistemas que crescem.

Se o seu processamento em background vive dentro da API, a única forma de escalá-lo é escalar a API inteira. Precisa de mais poder para processar a fila de jobs? Suba mais instâncias da aplicação web junto — mesmo que o tráfego HTTP nem precise disso.

Isso é ineficiente por definição. Em muitos sistemas reais, as cargas de background têm um perfil de escala completamente diferente da camada web: elas precisam crescer e encolher de forma independente. Acoplar os dois te força a pagar por capacidade que você não precisa, do lado errado.

A terceira dor: uma falha derruba o que não devia

Confiabilidade é o terceiro argumento, e talvez o mais convincente.

Quando o worker mora dentro da API, o raio de explosão de uma falha é a aplicação inteira:

• Se o worker quebra, você não quer que a API caia junto — mas, no mesmo processo, esse risco existe.
• Se você precisa reiniciar os workers, não deveria ter que reiniciar toda a aplicação web — mas, acoplado, é exatamente isso que acontece.

Separar o trabalho em background cria uma arquitetura muito mais resiliente: cada parte falha, reinicia e se recupera de forma isolada.

A solução: Worker Services como aplicações separadas

Para resolver esses três problemas — contenção de recursos, escala acoplada e falhas que se propagam — o .NET oferece os Worker Services.

Um Worker Service é uma aplicação independente, dedicada ao processamento em background. O modelo de programação parece familiar (ainda é um BackgroundService com seu loop), mas a diferença que importa é estrutural: é outro processo.

Isso destrava exatamente o que faltava:

• Recursos próprios — o worker não disputa CPU/memória com as suas requisições HTTP.
• Escala independente — você sobe mais instâncias do worker sem tocar na API.
• Ciclo de vida isolado — reiniciar ou derrubar o worker não afeta a aplicação web.

O melhor: como o Worker Service usa o mesmo generic host do ASP.NET, tudo que você já sabe — dependency injection, configuração, logging — continua valendo. Você ganha o isolamento sem reaprender a stack.

Checklist: está na hora de extrair o worker?

Use estes sinais como gatilho para tirar o background work de dentro da API:

• [ ] O trabalho é pesado (processa arquivos, gera relatórios, chama vários sistemas externos).
• [ ] Os tempos de resposta da API oscilam quando o background está ativo.
• [ ] Você precisa escalar o processamento sem escalar a camada web.
• [ ] Uma falha no processamento não pode colocar a API em risco.
• [ ] Você quer reiniciar/deployar o background sem mexer na aplicação web.

Se você marcou dois ou mais, o Worker Service deixou de ser luxo e virou decisão de arquitetura.

Conclusão

Hosted services dentro da API são ótimos — até deixarem de ser. No momento em que o trabalho fica pesado, precisa escalar sozinho ou não pode derrubar a aplicação, o lugar certo para ele é fora da API, em um Worker Service independente.

Já tem um BackgroundService rodando dentro da sua API hoje? Rode o checklist acima e veja se ele já não está te custando latência. No próximo post da série, vamos colocar a mão na massa e criar e estruturar o nosso primeiro Worker Service do jeito certo.