Five places to cache, five different problems

A browser cache is fastest and least controllable: once a response is on ten thousand devices with a long max-age, you cannot recall it. That is why immutable, content-hashed asset URLs are the right pattern for static files and the wrong pattern for anything whose meaning can change under a stable URL. A CDN cache is shared, close to users, and purgeable in seconds, which makes it the best place for anything public and identical for everyone.

Edge and application caches sit either side of your logic. An edge cache can hold a personalised fragment or a rendered page keyed on something you compute; an application cache, an in-process map or a shared Redis, holds the results of expensive work. In-process is fast and unshared, so with four instances you have four caches with four different ideas of the truth, and an invalidation that only reaches one of them.

Database caching is the layer people forget they already have. The query planner, the buffer pool and any materialised view are caches with their own warm-up behaviour, which is why the first query after a deploy or a failover is slow and why a benchmark that ignores warm-up is fiction. Before adding a cache in front of the database, check whether the database is already caching and you are simply missing an index.