Onde o Desempenho Vira Armadilha
O problema não está no modelo reativo. Está no que muitos times fazem com ele. Em nome de eficiência, criam fluxos tão complexos que só quem escreveu entende. **Over-engineering mascarado de “alta performance” é a porta de entrada da dívida técnica.**
Geralmente o caos começa aqui: um fluxo aparentemente simples vira um emaranhado de operators, mapeamentos, encadeamentos e retentativas escondidas. O sistema até responde rápido… até que alguém precise alterar uma regra de negócio.
A promessa de throughput alto se cumpre; a manutenibilidade evapora.
Resolver Sem Frescura: Reatividade com Limites e Propósito
Quem quer usar reatividade sem quebrar Arquitetura Limpa precisa entender uma regra simples: **fluxo reativo não é arquitetura — é detalhe de implementação**. Use-o nos limites: borda do sistema, I/O assíncrono, gateways. Nunca no coração das regras de negócio.
Sua solução pragmática começa com três pilares:
- Reatividade para I/O e não para modelar domínio.
- Orquestração simples: handlers curtos, operators previsíveis.
- Backpressure explícito — nunca “no default”.
Implementação de Sênior: Reatividade Sem Sacrificar Domínio
Um exemplo direto com Spring WebFlux, mantendo o domínio limpo e isolado:
public class ProcessarPagamentoUseCase {
public Resultado processar(DadosPagamento dados) {
// Regras de negócio puras, nenhuma dependência do reactor
if(dados.valor() <= 0) throw new IllegalArgumentException("Valor inválido");
return new Resultado("OK");
}
}
@RestController
public class PagamentoController {
private final ProcessarPagamentoUseCase useCase;
public PagamentoController(ProcessarPagamentoUseCase useCase) {
this.useCase = useCase;
}
@PostMapping("/pagamentos")
public Mono<Resultado> processar(@RequestBody Mono<DadosPagamento> body) {
return body
.limitRate(10)
.map(useCase::processar) // domínio intocado
.onErrorResume(e -> Mono.error(new RuntimeException("Erro no fluxo")));
}
}
Repare: a borda lida com reatividade, o domínio não sabe que Reactor existe. Simples, direto e sustentável.
O Custo Real: Ficar ou Não Ficar com Reatividade
Usar reatividade traz vantagens, mas também aumenta o custo cognitivo. **Performance não é grátis; você paga com complexidade.**
Trade-offs que importam:
- Escalabilidade maior, debugging mais difícil.
- Menos threads, mais operadores para entender.
- Menos bloqueio, mais necessidade de disciplina arquitetural.
Se seu time não domina o modelo, reatividade vira âncora — não vela.
Direto das Trincheiras
- Não inicie fluxo reativo dentro das regras de negócio. Mantenha o domínio puro.
- Use operators padronizados no time. Evite “criatividade” reativa.
- Monitore backpressure; ignorá-lo é receita de incidentes intermitentes.
Fontes consultadas
Dissertações/Teses – Portal de Programas de Pós-Graduação (UFBA)
universidade federal da paraíba – ufpb
ConfiabiIidade – Canal CECIERJ
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descascamos outros hypes da nossa área.
Valeu e até a próxima! 😉
