Describe architecture for live UI text updates without deployment
headless CMS design and cache invalidation for live content.
structured API, webhook sync, client or edge rendering with cache versioning, and rollback.
direct DB writes from the browser or ignoring CDN stale cache.
What's really being asked
This question evaluates whether you can decouple content from presentation using headless CMS architecture, design a real-time delivery pipeline, and reason about cache invalidation and consistency in production systems. Interviewers want to see you treat copy as structured data rather than hardcoded strings.
A GOOD ANSWER COVERS four layers in order. First, the authoring layer: a headless CMS with structured text schemas so copywriters edit fields, not code. Second, the transport layer: a real-time API or webhook that notifies the application of changes, plus a polling fallback for reliability. Third, the rendering layer: the app fetches copy at the edge or client-side so updates appear without redeployment, using techniques like stale-while-revalidate or short TTLs. Fourth, the cache and safety layer: versioned cache keys, surrogate key invalidation, feature flags for risky copy, and audit logs for rollbacks.
COMMON WRONG ANSWERS include proposing that the copywriter edits a JSON file in Git, which still requires deployment; suggesting the browser writes directly to a production database, which bypasses validation and security; or ignoring CDN and browser caches entirely, which leads to stale text for hours after an update. Another red flag is treating the problem as only a frontend concern without mentioning the content model or sync mechanism.
LIKELY FOLLOW-UPS include how you would handle A/B testing copy, how to prevent broken layouts when translated text is longer than the original, what happens if the CMS is down, and how you would backfill new text fields across thousands of existing pages without downtime.
A concrete example
imagine an e-commerce product page. The copywriter changes the return policy banner in Sanity. Sanity sends a webhook to your edge worker. The worker purges the surrogate key for that product page and updates a versioned cache key. The next request fetches the new copy from the CMS, serves it, and caches it for sixty seconds with stale-while-revalidate. The copy is live in under five seconds with zero deploys.
Interview question
How should you handle CDN caching in a headless CMS architecture to show live UI text updates within seconds without redeployment?
- a.Use versioned cache keys with surrogate-key invalidation triggered by CMS webhooksCorrect
- b.Use long-lived static cache keys and rely on natural TTL expiration
- c.Disable CDN caching entirely and fetch copy directly from the CMS on every request
- d.Store copy in a Git JSON file and rebuild the application on each edit
Why? this is the answer
Versioned cache keys with webhook-driven surrogate-key purging let edge caches reflect changes instantly without code deploys. Relying on Git-based workflows (D) still requires a full build pipeline, while disabling CDN caching (C) sacrifices edge performance.
Just read this? Test yourself on what you have been reading.
Read the original → sanity.io
- #headless cms
- #cache invalidation
- #system design
- #content architecture
- #edge caching
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles