mongona

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 backgr

ound 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 b

ackground 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 exis

te. 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 fal

ha 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 su

a 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.