Decide by two questions: who is the response for, and how fresh must it be?
Same for everyone → CDN. Examples are product listings, public articles and static assets. Cache them at the CDN with Cache-Control: public, max-age. The CDN then answers these requests, so they never reach your servers.
Personalised or needs authorisation → Redis. Keep the response off shared caches with Cache-Control: private or no-store. A shared cache like a CDN could show one user's data to another user. Instead, cache the expensive pieces in Redis, such as query results keyed by user or tenant (one customer organisation). Your server then builds the response quickly from these pieces.
Don't cache at all in two cases:
- The data must be exact on every read, like an account balance right after a payment.
- The data is cheap to compute and rarely repeated. The hit rate (share of reads served from the cache) will be low. You only add stale data and complexity.
Measure the hit rate and latency before and after you add a cache.
- Cache responses that are the same for everyone at the CDN, with public Cache-Control.
- For personalised responses, use private or no-store at the edge, and cache the parts in Redis.
- Key Redis entries by user or tenant where needed.
- Skip caching when data must be strictly fresh or is rarely reused.
- Measure the hit rate to prove the cache is worth it.
- HTTP caching (MDN) (https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching)developer.mozilla.org