Design architecture for multi-channel article distribution from a single source of truth

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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?

ONE 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.

Source: WordPress VIP