Performance Optimization

A Spring Boot API is almost always fast in development. The database holds thirty rows, it runs on the same machine, and a single user calls one endpoint at a time. Nothing can be slow under these conditions, which is exactly why performance problems are never discovered before production.

The gap comes from three differences that a development machine does not reproduce. Volume: a join without an index costs the same on thirty rows, but becomes a full scan on three million. Network latency: a SQL query goes from 0.1 ms locally to 2 ms against a remote server, and an operation that triggers two hundred of them goes from twenty milliseconds to four seconds. And concurrency: what works fine for one user can exhaust a connection pool at fifty.

The temptation, when facing a slow API, is to add caching. This is almost always premature: the cache masks the symptom, complicates invalidation, introduces inconsistencies, and fixes nothing. Before optimizing, measure; before caching, fix the root cause. In a typical Spring API, that cause is three times out of four the number of SQL queries executed, not their individual duration.