El ajuste de rendimiento en Spring Boot va sobre todo del límite con la base de datos: connection pooling, caching y acabar con el problema de consultas N+1. Mide primero (métricas de Micrometer + Actuator) y luego ataca el mayor coste.
Las asociaciones lazy lanzan una consulta por padre y luego una más por cada acceso a un hijo:
List<Order> orders = orderRepo.findAll();
(Order o : orders) {
o.getItems().size();
}
Arréglalo obteniendo la asociación en un único join:
@Query("SELECT o FROM Order o JOIN FETCH o.items") // una consulta, items cargados de forma eager
List<Order> findAllWithItems();
// O @EntityGraph(attributePaths = "items") en el método del repositorio.
HikariCP es el pool por defecto. Más grande no es mejor: demasiadas conexiones saturan la BD. Una fórmula común arranca cerca de cores * 2:
spring:
datasource:
hikari:
maximum-pool-size: 10 # ajústalo a la capacidad de la BD, no al número de threads
connection-timeout: 3000 # falla rápido en lugar de acumular peticiones
@Cacheable(value = "products", key = "#id") // sirve desde la cache tras la primera carga
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // invalida al escribir
public Product update(Product p) { return repo.save(p); }
Respáldalo con Redis (spring-boot-starter-data-redis) para una cache compartida entre instancias.
Las entrevistas senior evalúan si diagnosticas antes de optimizar. Las respuestas más fuertes nombran la herramienta que prueba el cuello de botella (activa spring.jpa.show-sql o datasource-proxy para contar consultas, lee la latencia p99 de Actuator), explican por qué un pool sobredimensionado perjudica, y tratan el caching como un problema de corrección —datos obsoletos e invalidación— no solo como una palanca de velocidad.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar