Dispatcher Caches a Personalized Header Across Users
A site serves a logged-in header (user name and cart count) rendered server-side by an AEM component. The Dispatcher config has a broad / cache rule with a 300s TTL and no /header exclusion. QA reports that after user A logs in, user B sometimes sees A's name and cart count. The header component reads the user from the request and outputs it in the same HTML document as the rest of the page. There is a CDN in front of the Dispatcher with its own 60s TTL. The page is otherwise public and cacheable. Traffic is roughly 5,000 req/min at peak.
1. Explain the caching failure end to end, including the CDN layer, and why a short TTL does not fix it.
Read the worked answer
The header is rendered into the same HTML document as public content, and the Dispatcher caches that document under / with a 300s TTL. When user A requests the page, the response includes A's name and cart count and is stored. User B's subsequent request within the TTL is served the cached document-A's data. The CDN in front adds a second cache layer with a 60s TTL, so even after the Dispatcher entry expires, the CDN can still serve A's page for up to a minute. A shorter TTL shrinks the window but does not eliminate it; any nonzero TTL means some user eventually sees another user's data. The root cause is caching a personalized response as if it were public-the cache key does not vary by user, and the response is not marked private.
2. What is the correct architectural fix, and what Dispatcher/CDN configuration enforces it?
Read the worked answer
Separate personalization from the cacheable document. The robust fix is to not render per-user data into the cached HTML: deliver the public page from cache and load the header's user-specific data via a client-side call to an uncached, authenticated endpoint (or an edge-side include if the CDN supports it). That endpoint must return Cache-Control: private, no-store and must not be cached by Dispatcher or CDN.
If server-side rendering must remain, then:
- Dispatcher: add a rule so the personalized URL is never cached (e.g., a
no-cacherule for the header fragment/endpoint), and ensure the main page does not embed user data. Do not rely on TTL tuning. - CDN: configure the personalized endpoint with
Cache-Control: private, no-store, no-cacheand bypass caching; setVaryappropriately if any shared caching remains, though for per-user data the correct answer is no shared cache. - Response headers: AEM should emit
Cache-Control: privatefor authenticated responses so intermediaries honor it.
At 5,000 req/min the uncached header endpoint must be sized for that load; caching the public page keeps the heavy document off the origin while the small header call scales independently.