Significantly Improving System Performance

Performance work has to start with measurement, not folklore — my rule is that if you cannot point to a flame graph or a query plan, you are guessing, and guessing at scale is expensive. Our Spring Boot catalog service had crept to multi-second p99 latency even after a couple of well-intentioned optimization attempts by other engineers. I attached async-profiler under Gatling-shaped load and the flame graph immediately pointed at Hibernate entity-graph serialization eating seventy-eight percent of CPU, not Postgres as everyone had assumed.

Slow-query forensics then revealed a lazy @OneToMany relationship exploding into hundreds of selects per request — the classic N+1 problem hiding behind a clean-looking repository interface. Replacing that with a single JOIN FETCH, adding a measured two-tier Caffeine plus Redis cache that settled at over ninety percent hit rate, and switching to lightweight DTO projections dropped p99 from about two seconds to under a hundred milliseconds without provisioning any new hardware. Database CPU utilization fell from the seventies to single digits during peak traffic.

The lesson I emphasize in interviews is that the bottleneck is rarely where people assume, and two engineers had already tried fixing the wrong layer. The most important optimization is not any single code change but building the discipline of baking Micrometer histograms and load-test gates into the everyday development workflow so performance regressions cannot accumulate silently for six months before somebody notices.