Measure before you optimize

You open the monitoring dashboard and notice GET /api/books is responsible for most of your database load. Every page load, every search, every catalog browse. The data barely changes, maybe a handful of new books per day, but the same query runs thousands of times an hour. That is the cache-shaped problem.

Before you reach for a cache, measure. Add structured logs or a basic APM and see which endpoints actually hurt. Caching a slow endpoint that gets called once an hour is wasted effort. Caching a fast endpoint that gets called a thousand times a minute is a huge win. The difference is the call count, not the latency.

No. Caches are not free. They add a layer that can go wrong, they require invalidation, and they introduce staleness. Only cache things that are read often, change rarely, and can tolerate a short stale window. Everything else is better off going straight to the database.