O tuning de performance no Spring Boot é majoritariamente sobre a fronteira com o banco de dados: connection pooling, caching e matar o problema de consulta N+1. Meça primeiro (métricas do Micrometer + Actuator), depois ataque o maior custo.
Associações lazy disparam uma consulta por pai e depois mais uma por acesso ao filho:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Corrija buscando a associação em um único join:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // one query, items eagerly loaded
List<Order> findAllWithItems();
// Or @EntityGraph(attributePaths = "items") on the repository method.
O HikariCP é o pool padrão. Maior não é melhor — conexões demais sobrecarregam o banco. Uma fórmula comum começa perto de cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # match DB capacity, not thread count
connection-timeout: 3000 # fail fast instead of piling up requests
@Cacheable(value = "products", key = "#id") // serve from cache after first load
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // invalidate on write
public Product update(Product p) { return repo.save(p); }
Apoie isso com Redis (spring-boot-starter-data-redis) para um cache compartilhado entre instâncias.
Entrevistas sênior testam se você diagnostica antes de otimizar. As respostas mais fortes nomeiam a ferramenta que prova o gargalo (ative spring.jpa.show-sql ou datasource-proxy para contar consultas, leia a latência p99 do Actuator), explicam por que um pool superdimensionado prejudica, e tratam o caching como um problema de correção — dados obsoletos e invalidação — não apenas como um botão de velocidade.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar