How do you approach diagnosing a slow endpoint in a Spring Boot application in production?
Quick Answer
Start with existing observability data (Micrometer's http.server.requests metrics broken down by endpoint, and distributed traces if available) to identify whether the slowness is in the application itself, a specific downstream call, or the database — before guessing. Check for common, high-probability culprits first: an N+1 query pattern, a missing database index, a downstream dependency that's degraded, or excessive object allocation/GC pressure. Reproduce the issue in a lower environment if possible to iterate safely, form a specific hypothesis backed by the data already gathered, and verify the fix with the same metrics/traces used to diagnose it in the first place.
Detailed Answer
A structured, evidence-first approach, rather than guessing at likely causes:
1. Start with existing observability data, not guesswork. If Micrometer/Actuator metrics are already being collected, http.server.requests broken down by endpoint/status immediately shows whether the slowness is isolated to one specific endpoint or system-wide, and whether it correlates with a deployment, a traffic spike, or a specific time window. If distributed tracing is available, a slow trace's span breakdown often points directly at which specific downstream call or database query is actually responsible, rather than needing to guess across the whole request path.
2. Check the highest-probability culprits first, since a handful of causes account for the overwhelming majority of real-world Spring Boot slow-endpoint incidents:
- N+1 query problems — enable SQL logging temporarily (or check existing APM tooling) to see if a single request is issuing far more queries than it logically should.
- A missing or ineffective database index on a column the query filters/joins on — check the query's execution plan (
EXPLAIN ANALYZE) if the database itself seems to be the bottleneck. - A degraded downstream dependency — if the endpoint calls another service, is that service currently slow? (This is exactly the scenario a circuit breaker and distributed tracing are meant to make immediately visible.)
- Excessive allocation / GC pressure — a sudden change in GC pause frequency/duration (visible in JVM metrics) correlating with the slowdown points at a memory/allocation-pattern regression rather than a query or downstream-call problem.
3. Reproduce in a safer environment when possible, rather than only ever experimenting directly against production — a staging environment with representative data volume/load lets you iterate on a hypothesis (add an index, batch a set of calls, adjust a connection pool size) without further risking the production system.
4. Form a specific, falsifiable hypothesis from the evidence gathered, rather than making several speculative changes simultaneously — e.g., "the trace shows 80% of this endpoint's latency is inside the inventory-service call, and that service's own metrics show its p99 latency spiked at the same time" is a specific, testable claim, not a vague guess.
5. Verify the fix using the same signal that originally surfaced the problem — if the diagnosis came from http.server.requests latency percentiles, confirm the fix actually moved that same metric, not just that the code change "looks correct."
What this communicates in an interview: a methodical, data-driven approach (use existing observability first, form a specific hypothesis, verify with the same signal) rather than jumping straight to plausible-sounding guesses — and genuine familiarity with the actual tools (Micrometer, distributed tracing, SQL logging/EXPLAIN) rather than just naming them abstractly.