Designing a Content Management System

A headless CMS separates content management from presentation, delivering via API to any channel.

Traditional vs Headless CMS

Traditional (WordPress):
  Content stored + HTML rendered on same server
  Tightly coupled to presentation

Headless CMS:
  Content stored in CMS
  Delivered via API to any frontend
  → Web, mobile, IoT, email

Content Model

{
  "content_type": "blog_post",
  "fields": [
    { "name": "title",     "type": "text",      "required": true },
    { "name": "slug",      "type": "slug",      "unique": true },
    { "name": "body",      "type": "richtext" },
    { "name": "hero_image","type": "media" },
    { "name": "author",    "type": "reference",  "to": "author" },
    { "name": "tags",      "type": "list",       "of": "text" },
    { "name": "published_at", "type": "datetime" }
  ]
}

Versioning and Drafts

content_versions:
  content_id, version, status, data, created_by, created_at

Status:
  draft      → Work in progress
  in_review  → Submitted for approval
  approved   → Ready to publish
  published  → Live
  archived   → Retired

Rollback: Republish any previous version

Publishing Pipeline

Editor clicks Publish
    ↓
Content Service marks version as published
    ↓
Event: content_published → Kafka
    ↓
CDN Purge Service → Invalidate cached content
    ↓
Search Index → Update Elasticsearch
    ↓
Static Site Generator → Rebuild affected pages (if SSG)

Multi-Channel Delivery

Content API:
  GET /api/content/blog-post/my-article
  Response: Structured JSON

Consumers:
  Web React app → Render HTML
  Mobile app    → Native rendering
  Email system  → HTML email template
  Smart speaker → Extract text only

Localization

content_translations:
  content_id, locale, translated_fields

Fallback:
  Request EN-GB → Check EN-GB → Fallback to EN → Error

Conclusion

Headless CMS decouples content from presentation. Content modeling flexibility, versioning, and multi-channel API delivery are the core architectural pillars.