The Most Expensive Optimization Is The One You Didn't Need
Premature optimization costs twice — the engineering time spent, and the complexity left behind. How to tell which optimizations are worth the trade.
- Production Lessons
- Performance
- Software Architecture
- System Design
One thing I've learned over the years is that engineers love solving difficult problems. Sometimes a little too much.
A page loads in 800ms. Someone suggests introducing Redis. Another proposes Kafka. Someone else recommends breaking the service into microservices.
All before answering one simple question: Where is the actual bottleneck?
I've seen teams spend weeks optimizing parts of the system that contributed only a few milliseconds to the total response time. Meanwhile, the real issue was a slow database query. Or a missing index. Or five sequential API calls. Or simply fetching far more data than the client needed.
The lesson wasn't that caching, queues, or microservices are bad. They're incredibly powerful.
But only when they're solving the right problem. One mindset that has saved me from unnecessary complexity is this: Measure first. Optimize second.
Architecture should remove bottlenecks. Not introduce new ones.
The best optimization isn't always the most impressive one. Sometimes it's deleting unnecessary work instead of adding new technology.
Keep reading
The Most Dangerous Assumption in Distributed Systems
"This request will only happen once" causes more production incidents than almost anything. Why state-changing actions should assume they may arrive twice.
The Biggest Architectural Mistake? Optimizing for the Happy Path
Most architectures are designed for everything going right. Why the failure paths deserve as much design attention as the success path.
The Best Systems Aren't The Ones That Never Fail
Reliability is not the absence of failure, it is graceful behaviour during one. Designing systems that degrade instead of collapsing.