Caching in .NET: The Fastest Code Is the Code You Never Execute
One of the easiest ways to improve application performance isn't buying bigger servers or rewriting algorithms. It's avoiding unnecessary work altogether. That's exactly what caching does. Done correctly, caching can reduce latency by orders of magnitude. Done poorly, it becomes one of the hardest bugs to diagnose.
1. Cache expensive work, not everything
A common mistake is trying to cache every request. Instead, ask:
- Is the data expensive to compute?
- Does it change infrequently?
- Is it requested often?
If the answer is yes, it's probably worth caching.
2. Understand your cache lifetime
Every cached item has an expiration strategy. Choosing the wrong one is usually worse than having no cache.
- Absolute expiration
- Sliding expiration
- Manual invalidation
- Event-driven invalidation
The lifetime should reflect how often the underlying data actually changes.
3. Memory cache isn't always enough
ASP.NET's in-memory cache is extremely fast. But every application instance has its own copy. Once you have multiple servers or containers, consistency becomes difficult. That's where distributed caches such as Redis become valuable.
4. Beware the cache stampede
Imagine one thousand requests arriving immediately after a cache entry expires. Without protection, every request recomputes the same expensive operation simultaneously. This "cache stampede" can overload databases and downstream services. Techniques like request coalescing, locking, or background refreshes help prevent it.
5. Don't cache bad data
Errors, incomplete objects, or partially loaded data can become surprisingly persistent once cached. Always validate before storing results.
6. Measure cache effectiveness
A cache isn't useful simply because it exists. Track metrics such as:
- hit rate
- miss rate
- evictions
- memory usage
- average lookup time
Without metrics, you're guessing.
7. Caching is an architectural decision
Caching affects consistency, scalability, and operational complexity. It shouldn't be sprinkled into code randomly. Think about invalidation, monitoring, and failure behavior from the beginning.
Final takeaway
Performance isn't only about writing faster code. It's about doing less work. The fastest database query is the one you never send. The fastest API call is the one you never make. And the fastest code is often the code that never executes because the answer was already waiting in the cache.