When designing a web service,
four approaches to decide how to manage and deliver content
First look at how the structure is split, then look at who operates it
Architecture axis: how content management and presentation (HTML generation) are split
One system handles both content management and presentation (HTML generation).
Content is managed through APIs, while presentation (HTML generation) is implemented by a separate frontend.
Operating axis: delegate a feature to an external SaaS or run it yourself
Delegate features like comments, search, or analytics to an external service via script or SDK.
Install open-source tools or services on your own infrastructure and operate them directly.
A website-first CMS with comments, search, or analytics delegated to external SaaS tools
Drupal or TYPO3 installed and operated on your own infrastructure
Contentful or Sanity combined with Next.js or Astro for fast delivery
Strapi, Directus, or Payload operated directly for stronger data control
Monolithic vs Headless answers a structure question, while SaaS vs Self-hosted answers an operating-ownership question.
Scan the four patterns at once and see when each should be your first candidate
One system handles both content management and presentation (HTML generation).
Content is managed through APIs while presentation is built in a separate frontend.
Keep some pages in the existing CMS while moving selected areas to a separate frontend.
Delegate features like comments, search, or analytics to separate services.
| Aspect | Monolithic | Headless | Hybrid | Embed |
|---|---|---|---|---|
| Presentation (HTML generation) | CMS generates HTML directly | Separate frontend generates HTML | Generation split by route or surface | Internal services answer feature requests |
| Key advantage | Simple build, integrated backoffice | Multi-channel expansion, frontend freedom | Gradual separation, lower migration risk | Fast feature adoption, selective separation |
| Cache strategy | HTML/static asset CDN | API + ISR/Edge cache | Per-route cache split | Per-feature cache and queue operations |
| When to consider first | When the website is the main channel | When web, app, and API must move together | When you want to improve only part of an existing CMS | When comments/search/analytics need a fast add-on |
Start by checking who generates HTML, then compare cache strategy and operating complexity to narrow the candidates quickly.
Traditional structure with content management and presentation coupled
A structure where the content backoffice (admin UI) and presentation (templates/themes) are coupled in one system. Frontend and backend are essentially bound together, with functionality extended through themes and plugins.
License, strengths, and operational considerations
Modern structure delivering content via API
Separates content storage/management (backend) from presentation (frontend), delivering content via REST/GraphQL to any channel. Frontend tech stack (React, Vue, Astro, etc.) is freely selectable.
SaaS vs Self-hosted comparison
How will you operate your CMS?
This is a different axis from Monolithic vs Headless. Both Monolithic and Headless CMS can be operated as SaaS (cloud) or Self-hosted (self-installed). Cloud vendors (AWS, GCP, Azure) also provide tools to deploy these open-source CMS products on their infrastructure.
Delegate features to external services, embed via script
Delegate features like comments, search, analytics, and auth to external SaaS, embedding them via JS/SDK. Fastest to integrate, but security, privacy, and performance control costs grow over time.
These are the operating concerns that usually come with embedding third-party SaaS features.
Who is responsible for what
Recommended stacks by situation
A practical setup where page building starts fast, while the vendor handles server ops, security patches, and updates.
Minimize external data transmission. Run PostHog, Sentry self-hosted on internal network
Regular content export pipeline (CLI backup) · Isolate SaaS Embed with CSP/SRI · Confirm billing units (MAU/events/requests/records) upfront
In practice, teams often mix structures and migrate step by step
The comparison on slides 2 and 3 is meant to explain the conceptual axes. In real services, teams rarely switch everything at once. They usually separate only the parts that need it first.
When does the screen update after publishing in a CMS?
"Why doesn't the page update immediately after editing?" The answer is almost always the cache. Even if you fix the DB, the CDN or frontend may still serve old results.
Design covers not just content but also roles, revisions, and audit logs
A CMS DB is not a simple post storage. It must handle who can edit, when content was published, and whether rollback to a past version is possible.
Connected to posts, comments, and audit logs
Linked to revisions, tags, and media
A full snapshot copy of a past version
Goes through approval queue for XSS/spam defense
Also design: ROLE, PERMISSION, USER_ROLE, MEDIA, TAXONOMY, AUDIT_LOG
Who can do what
| Resource/Action | Guest | User | Author+Publisher | Admin |
|---|---|---|---|---|
| Content read (public) | ✅ | ✅ | ✅ | ✅ |
| Content create (draft) | ❌ | Optional | ✅(own) | ✅(any) |
| Content edit | ❌ | ❌ | ✅(own) | ✅(any) |
| Content publish | ❌ | ❌ | ✅ | ✅ |
| Content rollback | ❌ | ❌ | ✅(granted) | ✅ |
| Comment create | ✅ | ✅ | ✅ | ✅ |
| Comment approve/delete | ❌ | ❌ | ✅(granted) | ✅ |
| User/Role management | ❌ | ❌ | ❌ | ✅ |
Draft → Review → Publish → Rollback
Authors and approvers can be different people. A workflow manages the create-review-publish process consistently.
CMS has a wide attack surface: user input, permissions, scripts, media
The checklist is not a memorization list. It is a question checklist: "Is this input dangerous?", "Are permissions too broad?", "Can I trust this external script?"
| Area | Check | Level |
|---|---|---|
| Authentication | Password hashing, MFA (optional), login attempt limiting | critical |
| Authorization (RBAC) | scope (own/any), admin function separation | critical |
| XSS | Output encoding, HTML Sanitization, editor allowed-tag restriction | critical |
| CSRF | CSRF token / Origin check on state-changing requests | high |
| CSP | Strict script-src with nonce/hash, block inline scripts | high |
| SRI | Apply integrity attribute to external scripts | high |
| Secret Mgmt | Separate DB/token keys via Secret Manager, no secrets in code | critical |
| Audit Log | Always log publish, rollback, and permission changes | high |
What system moves at what moment
A closer look at the Presigned URL pattern
Small text requests are usually fine for the application server to handle directly. Large files such as video are different. If the web server receives them directly, bandwidth, concurrent connections, and temporary storage pressure can all pile onto the app tier and trigger cascading failures.
Here, "Browser → direct PUT to S3" does not mean a full-page HTML form submit. It means JavaScript in the browser performs an asynchronous upload with fetch/XHR. That makes it possible to show upload progress, retry failures, and register metadata after the file upload finishes.
Cache, DB scaling, disaster recovery
| Component | RTO | RPO |
|---|---|---|
| Content DB | 1-4 hours | 5-15 min |
| Media Storage | 1-4 hours | 15-60 min |
| Cache/Search Index | Minutes to 1 hour | Rebuildable |
These values are starting points. Adjust based on your team's operations policy and budget.
Compare Monolithic, Headless, SaaS Embed, and Self-hosted choices through a real service-ops lens.
A structural design course for beginners on where content lives, which features to outsource, and how cache and permissions shape the system.
Deliverable: a CMS decision matrix, an initial content model, and cache/permission operating checklists for your product.
Separate Monolithic vs Headless from SaaS vs Self-hosted so the comparison becomes easier to reason about.
Go beyond pros and cons and learn when each pattern should become a first candidate.
Choose practical stack combinations based on team size, data sensitivity, ops strength, and cost shape.
Connect revisions, RBAC, audit logs, and cache invalidation as implementation-level concerns.
Review how moderation queues, large uploads, disaster recovery, and observability fit into the operating model.