Otimização de desempenho

Uma API Spring Boot quase sempre é rápida em desenvolvimento. O banco tem trinta linhas, roda na mesma máquina, e um único usuário chama um endpoint por vez. Nada pode ficar lento nessas condições, e é justamente por isso que os problemas de desempenho nunca aparecem antes da produção.

A diferença vem de três fatores que o ambiente de desenvolvimento não reproduz. O volume: uma junção sem índice custa o mesmo em trinta linhas e vira uma varredura completa em três milhões. A latência de rede: uma consulta SQL passa de 0,1 ms em local para 2 ms em um servidor remoto, e uma operação que dispara duzentas consultas passa de vinte milissegundos para quatro segundos. E a concorrência: o que funciona bem para um usuário pode esgotar um pool de conexões com cinquenta.

Diante de uma API lenta, a tentação é adicionar cache. Isso quase sempre é prematuro: o cache mascara o sintoma, complica a invalidação, introduz inconsistências e não corrige nada. Antes de otimizar, meça; antes de usar cache, corrija a causa. Em uma API Spring típica, essa causa é, três vezes em quatro, o número de consultas SQL executadas, e não a duração individual de cada uma.