Can I cache Croct content API responses to cut request volume?
The marketplace I work on has hot category pages that get hammered, and I am looking at putting a cache in front of the content fetches for them, same as we do for every other upstream. But the responses are personalized per visitor, so I am not sure what is actually safe to cache without serving someone content that was resolved for a different audience.
Is there a sanctioned caching story here? What is safely cacheable and what absolutely is not
2 answers
The dividing line is whether the response depends on the visitor.
Personalized responses are per-user by definition, that is the whole point of the resolution. Putting a shared cache in front of them defeats it: the first visitor's resolved content gets replayed to everyone behind them, and your experiences and experiments silently stop doing anything for the cached share of traffic. So the rule is simple, keep shared caching for content that is identical for everyone and let personalized slots resolve per request. The per-request path is cheap enough that this is not the hardship it sounds like.
For the content that genuinely does not depend on the visitor, the content service exposes a static-content endpoint. That is the sanctioned cacheable path: same payload for every requester, so a shared cache in front of it is correct by construction. Splitting your fetches along that line, static endpoint behind cache for the shared parts, per-request resolution for the personalized slots, gets you most of the request-volume win without breaking anything.
One tool that helps you audit the boundary: the response metadata tells you what you actually got. contentSource comes back as "slot", "experience", or "experiment" along with the matching experience, experiment, and variant IDs. If you log that per route, you can see empirically which routes only ever return plain slot content (candidates for the static path) and which ones return experience or experiment resolutions (must stay per-request). Much safer than deciding from the CMS side what you believe is personalized.