Challenge 3: Caching a Per-User Dashboard by URL Alone — Solution Walkthrough

What could go wrong:

If the cache key is just the URL, the cache has no way to
distinguish "User A's dashboard" from "User B's dashboard" when both
users request the exact same URL path (e.g. /dashboard). The first
user to request that URL gets their own personalized page generated
and stored in the cache; every subsequent request to that same URL —
from any other logged-in user — would then be served that exact same
cached response, showing one user's private account data to a
completely different user.

Why this is more serious than a typical performance misconfiguration:

Most performance misconfigurations (overusing gzip, badly tuned
keep-alive timeouts) only cost efficiency — pages load a bit slower,
or the server uses more resources than necessary. This is a data
exposure issue: private, personalized information ends up delivered to
someone who has no right to see it, purely because the caching layer
treated two different, unrelated requests as if they were
interchangeable. That's a security incident, not merely a slow page.

The correct approach:

Personalized or session-specific content generally shouldn't be cached
by URL alone at all — either exclude it from caching entirely, or
build a cache key that genuinely accounts for what varies between
requests (e.g. including the user's session identity), so two
different users' requests to the same URL are never treated as the
same cacheable response.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own warning box to a concrete,
realistic caching bug — correctly identifying both the mechanism
(cache key doesn't account for per-user variation) and why this
specific category of mistake is qualitatively worse than an ordinary
performance-tuning error.