What's the difference between a CDN cache and caching inside my own app?

A CDN cache sits outside your infrastructure and near the person asking, so it can only judge a request by what is on the wire: the address, the method and a few headers. A cache inside your own process sits behind the network and can key on anything the request carries, including who sent it. That is the difference that matters. Both hold copies to save work, but they can see different things about a request, and what a cache can see decides what it is allowed to hold.

Reading the ladder of places a copy can live, from the user's own device down through a point of presence, a service process, a shared tier, then the store, each step down is slower to reach and serves more people. Position is not a deployment detail. It sets the unit of sharing.

A request answered by a point of presence near the user costs 18 milliseconds. The same request crossing to the data centre costs 112 milliseconds, so 94 of those milliseconds are geography, and nothing you do inside the data centre touches them.

Now put a cache inside the process. A hit there costs about 0.0002 milliseconds, because it is a pointer follow with no socket and no serialisation. The 0.4 milliseconds to the shared tier is a real round trip by comparison. But the hit in the process is only reached after the 112 milliseconds have been paid, so it saves 0.4 milliseconds out of 112.4, not 112.

The other cost of living inside a process is multiplicity. Forty processes means forty copies, forty expiry schedules and forty things an invalidation has to reach, and no copy knows what the others hold. A popular item that goes cold produces forty fetches to the store rather than one, because each process misses on its own. Two users asking the same question can land on different processes and get answers of different ages, which produces a bug report nobody can reproduce.

The natural guess is that these are the same cache in different places, so the only question is which one is faster. That guess fails on the first request that differs per user. A CDN cannot tell who is asking unless you put the identity into the address or a header, and the moment you do, the copy is no longer shared and the edge stops being able to help. A cache in your process has the identity and can key on it, which is exactly why it can hold a personal answer, and exactly why it cannot be purged in one place. One purge at the edge reaches every copy of that entry, because there is at most one copy per point of presence.

The useful move is usually not to pick a rung but to split the answer across two. There are 94 milliseconds of pure geography between the user and the data centre. If the shell of the page, the part every user receives identically, is held at the point of presence, that shell arrives in 18 milliseconds, and only the small personal remainder travels the 94. The page becomes fast for everyone without the edge ever holding a personal answer.

Two questions settle which part goes where. Who else wants this answer, and how old may it be? Something wanted by everybody that may be minutes old belongs as far out as it will go. Something wanted by one person that must be current stays close in, or is not cached at all.

The in-app cache stops being the wrong choice when the item is personal, changes on a timescale of seconds, and you cannot afford even the 0.4 millisecond shared-tier round trip. It also degrades in a specific way as you scale: each local cache sees a smaller slice of the total traffic, warms more slowly, and duplicates the misses of its neighbours, so a layer that absorbed nearly everything at one process absorbs a fraction of it at forty. The edge has the opposite failure. It stops being usable the moment a response varies on a cookie, on an authorization header, or on anything else that changes per request, because then no two users can share it and there is nothing for it to hold.