Marketing wants personalised content on pages currently cached at the edge with a 24-hour TTL. Preserve the performance.

What the interviewer is testing

Whether you decompose the page by cacheability rather than accepting an all-or-nothing choice.

The trap

Making the whole page personalised makes it uncacheable, so every request reaches origin. Load rises sharply, latency rises, and the CDN's benefit disappears — for a personalised element that is usually a small fraction of the page.

The techniques

Split by cacheability. The shell, navigation, layout and non-personalised content stay cached. The personalised fragment is fetched separately — client-side after initial render, or composed at the edge. The user gets fast first paint; personalisation fills in.

Cache by segment rather than by user. If personalisation resolves to one of twenty segments, cache twenty variants keyed by a segment cookie. This preserves a high hit rate while delivering differentiated content, and it covers most of what marketing actually wants.

Edge compute with edge-replicated segment data, running the personalisation logic at the edge so no origin call is needed at all.

Reserve full origin rendering for genuinely per-user content, on the routes that need it.

The interrogation that usually resolves it

"Personalised" frequently means segment-based rather than individual — returning versus new visitor, region, product interest, membership tier. Establishing that distinction before designing removes the conflict entirely, because segment caching delivers it at near-full performance.

The consequence to manage

Fragments arriving after initial render cause layout shift unless space is reserved. Cumulative Layout Shift is a Core Web Vital and a real annoyance, so placeholders with reserved dimensions are mandatory rather than optional.

What a strong answer adds

Requiring the value to be measured: personalisation costing 400 ms of latency should demonstrate a conversion improvement exceeding the well-documented conversion cost of that latency. That turns an assumption into a testable claim.

And the general caching principle it illustrates: separate content by rate of change and cache each accordingly. The most common caching failure in web architecture is exactly this — dynamically composing a page makes the whole response uncacheable when the volatile portion was a small fragment.

Common weak answers

Disabling edge caching for those pages. Refusing personalisation on performance grounds without offering segment caching.