Performance tuning in Spring Boot is mostly about the database boundary: connection pooling, caching, and killing the N+1 query problem. Measure first (Micrometer + Actuator metrics), then attack the biggest cost.
Lazy associations issue one query per parent, then one more per child access:
List<Order> orders = orderRepo.findAll(); // 1 query
(Order o : orders) {
o.getItems().size();
}
Fix it by fetching the association in a single 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.
HikariCP is the default pool. Bigger is not better — too many connections thrash the DB. A common formula starts near 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); }
Back it with Redis (spring-boot-starter-data-redis) for a shared cache across instances.
Senior interviews test whether you diagnose before you optimize. The strongest answers name the tool that proves the bottleneck (enable spring.jpa.show-sql or datasource-proxy to count queries, read p99 latency from Actuator), explain why an oversized pool hurts, and treat caching as a correctness problem — stale data and invalidation — not just a speed knob.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate