When traffic grows, performance issues are often not caused by weak hardware—they are caused by repeated work. The same expensive queries, API calls, and rendered payloads happen again and again.
Caching reduces that repeated work. Done well, it lowers latency, cuts infrastructure cost, and improves user experience during peak traffic.
The key takeaway
Cache at the layer that fits the read pattern: CDN for static assets and cacheable pages, Redis for frequently requested computed data and query caching for heavy, stable reads. Profile read traffic first, use short TTLs or event-driven invalidation, guard against stampedes and track latency, hit ratio and cost after rollout.
Use the Right Cache at the Right Layer
- CDN Cache: Static assets and cacheable page responses close to users
- Application Cache (Redis): Frequently requested computed data
- Database Query Cache: Heavy reads with stable result windows
Start with Read Patterns, Not Tools
Before selecting a cache technology, profile read traffic by endpoint and query cost. This reveals which paths produce the highest latency and compute waste. For the database side, see PostgreSQL versus MongoDB performance decisions.
TTL and Invalidation Principles
- Use short TTL for volatile data
- Use event-driven invalidation for business-critical updates
- Avoid global cache flushes unless absolutely necessary
- Include tenant/user context in cache keys where required
For tenant-aware cache keys, see multi-tenant SaaS architecture patterns.
Performance Metrics to Track After Rollout
- p95 and p99 latency by endpoint
- Database CPU and query volume reduction
- Cache hit ratio and miss penalty
- Infrastructure cost per 1,000 requests
Caching is most effective when treated as architecture, not a patch. A layered strategy across CDN, application, and data access can unlock major performance gains while keeping correctness intact. See how we apply this in our client case studies.
Questions and answers
What are the main types of caching for web applications?
CDN cache for static assets and cacheable page responses close to users, application cache (Redis) for frequently requested computed data, and database query cache for heavy reads with stable result windows. Each layer solves a different performance problem.
How do I choose the right TTL for cached data?
Use short TTLs for volatile data that changes frequently. Use event-driven invalidation for business-critical data where staleness has real consequences. Avoid global cache flushes — they cause stampede effects. Always include tenant or user context in cache keys for multi-tenant systems.
What is a cache stampede and how do I prevent it?
A cache stampede happens when many requests hit the origin simultaneously after a cache entry expires. Prevent it with request coalescing — the first miss fetches from origin, subsequent requests wait for that result rather than all firing separately. Implement stale-while-revalidate for resilience.
What metrics should I track to know if my caching strategy is working?
Track p95 and p99 latency by endpoint before and after caching rollout, database CPU and query volume reduction, cache hit ratio (aim for >80% for hot paths), and infrastructure cost per 1,000 requests.