How we diagnose performance
Finding the actual constraint behind a performance problem before reaching for more infrastructure — which is often smaller, cheaper, and permanent rather than a bigger instance.
The situation
A platform slowing down as it grew, with the usual first instinct being to increase instance sizes — a response that hides the underlying problem while permanently raising the running cost.
What we did
Measured before changing anything, and looked past the average response time to the slower end of the distribution — the experience of the accounts with the most data, which an average conveniently hides.
What we typically find underneath
- A query pattern that issues far more database calls than the page actually needs.
- Database connections opened and closed per request instead of pooled, which becomes the real ceiling on throughput.
- No caching in front of content or queries that repeat constantly and change rarely.
- Work that could run asynchronously instead running inside the request itself, so users wait on it unnecessarily.
What we changed
Fixed the query pattern first, since it was cheap to fix and largest in effect. Introduced connection pooling, added caching where it mattered, and moved long-running work off the request path.
Result
Meaningfully lower latency at the point that actually affected users, achieved without adding infrastructure — in this case, the team ended up on smaller instances than they started with, not larger ones.
- RDS Proxy
- CloudFront
- Application caching
- Autoscaling
These describe our approach to each type of engagement, illustrated by the kind of situation and findings we see repeatedly. They are not attributed to a named client.