A Cache You Do Not Operate
The previous lesson ended with a mechanism whose behaviour was decided by resolvers nobody in your company controls. This one is the same shape again, with the stakes moved from routing to content.
A is a cache in front of your origin, run by somebody else, in thousands of places at once. Both halves of that sentence matter. The first half is why people buy one. The second half is where all the difficulty comes from.
A miss adds a hop, so the first user waits for both legs of the journey. The economics only work because misses are rare, and misses are only rare if the cache key is right.
That last sentence is the whole lesson.
The Cache Key Decides Everything
Two requests with the same key share one stored copy. Two requests with different keys are two separate objects, even when the bytes are byte for byte identical. Nothing here is about your content, and everything is about what the edge decides it may reuse.
A cache key that is too broad serves the wrong content to somebody. A cache key that is too narrow serves the right content and stores a separate copy for every visitor, which is a cache that never hits. The second failure is far more common and much harder to notice, because nothing breaks.
Every write-up of this subject states the same rule: the query string is part of the cache key, so appending a tracking parameter fragments your cache. It is a good story with a clear villain. It was also worth checking.