The Fastest Query Is the One You Never Execute
The dashboards looked healthy, yet users said the app felt slow. The culprit wasn't an expensive query — it was the same query running over and over again.
- Production Lessons
- Caching
- Performance Engineering
- System Design
- Software Architecture
A production incident once taught me a lesson I'll never forget.
- The dashboard looked healthy.
- CPU usage was normal.
- Memory was stable.
- The database wasn't overloaded.
Yet users kept reporting that the application felt slow.

After tracing a few requests, the problem became obvious. The application wasn't running expensive queries. It was running the same query over and over again.
Every request asked for data that had already been fetched seconds earlier. Nothing was technically broken.
The system was simply doing unnecessary work. That's when I realized something that changed how I think about performance.
Most performance problems aren't caused by slow code. They're caused by repeated work.
When a request arrives, ask yourself:
- Do I already have this data?
- Has it actually changed?
- Does this request need the database?
- Can this response be safely reused?
Those questions often matter more than adding another database index.
Great production systems don't just execute queries efficiently. They avoid executing queries that don't need to happen.
That's why caching, request deduplication, and precomputed results have such a huge impact at scale.
Not because databases are slow. But because every unnecessary query competes with the ones that actually matter.
One lesson I carry into every architecture discussion is this: Optimization isn't always about making systems work faster. Sometimes it's about making them work less.
What's the biggest performance improvement you've seen that came from removing work instead of optimizing it?
Keep reading
Why Some Systems Crash at 1,000 Users While Others Handle Millions
A system doesn't become slow because more users arrive — it becomes slow because one component reaches its limit. Traffic exposes bottlenecks; it doesn't create them.
Why More Servers Won't Always Fix Your Performance Problems
Doubling the server count and still slow — because the bottleneck was never the web servers. Why scaling means finding what can't scale, not adding capacity everywhere.
How Does Netflix Load Your Home Screen So Fast?
Netflix doesn't build your home screen after you open the app — it prepares most of it before you arrive. Why precomputation and caching beat request-time work.