A show title is public catalog data. A flag saying that a particular listener follows the show is private application state. Combining both into one cached response can expose the private part if the response is later reused for another person.
Design cache boundaries before adding a CDN or a shared response cache.
Split the data where possible
A public catalog cache can store stable show or episode metadata under a catalog ID. Your application can then combine it with private listener state in an authenticated layer. Keep account ownership in private cache keys and respect the backend's cache instructions.
Do not assume that the presence of an authorization header automatically makes every framework cache safe. Review the actual behavior of your proxy, server framework, service worker, and client library.
A cache entry for “search results” should include the query, filters, sort, and other inputs that affect the result. A personalized home feed also needs a listener boundary. A missing input can return a technically valid response to the wrong request.
Use two test accounts
Request the same show as account A and account B, with different follow states. Repeat through the caching layer your production deployment will use. B must not receive A's follow flag, history, or resume position.
Then sign out and visit the same route anonymously. The public page should remain public without carrying the last authenticated response.
Log cache hits using safe keys or hashes, not raw credentials. Cache performance matters, but a high hit rate is not useful if the cache crosses an account boundary. Keep public reuse and private continuity as separate design goals.