System Design/03 - Qualidade/Performance Antipatterns2 min
Busy Frontend
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Executar trabalho pesado no caminho da requisição, na camada que atende usuários — em vez de delegá-lo a processamento em segundo plano.
Cada requisição bloqueada consome uma thread, uma conexão e memória. Sob carga, o pool esgota e requisições rápidas passam a esperar por causa das lentas.
Formas comuns
| Trabalho no request | Deveria ser |
|---|---|
| Gerar PDF ou relatório | Job assíncrono, resposta 202 |
| Processar imagem/vídeo no upload | Fila + worker |
| Enviar e-mail síncronamente | Fila |
| Chamar três APIs externas em sequência | Paralelo, ou assíncrono |
| Importar arquivo grande | Upload + job |
O nome "frontend" aqui significa camada de entrada (a que recebe requisições), não interface de usuário.
Trade-offs
Mover o trabalho para segundo plano custa complexidade real: agora o resultado precisa voltar de alguma forma (Returning Results), o job precisa ser idempotente, precisa de retry, precisa de monitoramento próprio, e o usuário precisa de feedback de progresso.
Para um trabalho que leva 200 ms e é raro, esse custo não compensa — a resposta síncrona é mais simples e boa o suficiente. O antipadrão só se materializa quando duração × frequência ameaça o pool.
Há também um efeito colateral positivo frequentemente ignorado: separar o trabalho pesado permite escalar as duas camadas independentemente. Um pico de uploads passa a aumentar a fila e o número de workers, sem afetar a latência de quem só está navegando.
E o inverso do antipadrão — assincronizar tudo — cria seu próprio custo: uma operação que poderia ter respondido em 50 ms passa a exigir polling, estado e três componentes.
Exemplo prático
Um endpoint de upload de vídeo que transcodifica antes de responder.
POST /videos → transcodifica (3 min) → 200 OK
Com um pool de 50 threads, 17 uploads simultâneos consomem todo o pool por três minutos. Durante esse período, toda a API — inclusive endpoints triviais — fica indisponível. O sistema não caiu por falta de CPU; caiu por falta de threads.
POST /videos → grava o arquivo → publica na fila → 202 Accepted (200 ms)
workers → transcodificam em paralelo, escaláveis à parte
A mesma máquina passa a absorver centenas de uploads simultâneos, e a fila torna o excesso visível como métrica em vez de indisponibilidade.
Relacionado
Parte de Performance Antipatterns · roadmap.sh/system-design