Design architecture for multi-channel article distribution from a single source of truth
Tests separation of content and presentation via headless CMS. Strong answers cite a central structured CMS, content API, channel-specific rendering layers, and webhook push. Red flag: manual duplication or direct database sharing without API abstraction.
What's really being asked
The interviewer is checking whether you can design a decoupled content architecture that treats channels as consumers rather than silos. They want to see understanding of structured content, API-first delivery, and the practical difference between multichannel duplication and true omnichannel distribution from one source of truth.
The full answer
First, a headless CMS or structured content repository acting as the single source of truth, storing content in channel-agnostic fields such as title, body, excerpt, author, and tags instead of presentation-heavy HTML blobs. Second, a content API, usually REST or GraphQL, that exposes these structured fields to any authenticated consumer. Third, channel-specific rendering layers: the website might use a React or Vue frontend, the mobile app consumes JSON directly into native components, and the email service transforms structured content into responsive HTML templates at send time. Fourth, an update propagation mechanism such as webhooks, an event bus, or pub-sub messaging so that publishing or editing an article triggers near real-time cache invalidation or content refreshes across web, app, and email systems. Fifth, explicit handling of channel adaptations like character limits for push notifications, image cropping for mobile viewports, or plain-text fallbacks for email clients.
The mistakes people make
Treating the main website database as the source of truth and giving the mobile app direct SQL access, which couples channels to one schema. Proposing manual copy-paste workflows where editors recreate articles in separate email and app systems, which defeats the single-source requirement. Suggesting a single shared HTML blob that all channels render identically, which breaks mobile layouts and email client compatibility. Ignoring structured metadata and storing only rich text, forcing every downstream channel to parse unstructured content.
What usually comes next
How would you handle channel-specific personalization or A-B testing without fragmenting the source of truth? What caching strategy prevents the CMS API from being overwhelmed by traffic across three distinct channels? How do you ensure email rendering consistency across dozens of email clients when transforming structured content? What happens when the mobile app needs offline support or a different article ordering than the website?
A concrete example
Imagine a newsroom using WordPress VIP as the headless CMS. An editor publishes an article with structured fields for headline, dek, body, hero image, and summary. The website queries the GraphQL API at build time for static generation. The mobile app fetches the same article via REST for native rendering in a scrollable feed. The email platform subscribes to a publish webhook, transforms the summary and hero image into responsive email HTML via a template engine, and queues the campaign. When the editor updates the headline, the CMS emits an event that invalidates the website CDN cache, triggers an in-app content refresh, and regenerates the pending email draft, all within seconds.
Interview question
In a decoupled multi-channel architecture, how should article content be stored and delivered to consumers?
- a.In the website's database with direct SQL access granted to mobile and email services
- b.As a single shared HTML blob rendered identically by all channels
- c.As rich text only, requiring each channel to parse the unstructured content for its own needs
- d.In structured, channel-agnostic fields exposed via an API with channel-specific rendering layersCorrect
Why? this is the answer
Storing content in structured, channel-agnostic fields and delivering it through an API lets each channel render appropriately, while a shared HTML blob is tempting but wrong because forcing identical presentation breaks mobile layouts and email compatibility.
Just read this? Test yourself on what you have been reading.
Read the original → wpvip.com
- #architecture
- #headless-cms
- #api-design
- #content-distribution
- #omnichannel
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. Open roles that interview on architecture — each one lists the topics its interview covers.
See open roles