CMS and Website: Direct Access or Decoupled Delivery?

Direct website access to the editorial system is enough for a single output channel, a low change frequency and no planned replacement. If further channels, high load or a system replacement come into play, a decoupled delivery index with a content API pays off.

Anyone deciding on an editorial system today is rarely deciding on an editorial system alone.

What will our next output channel cost us? The answer to this question is not in the requirements specification of the editorial system. It is in the data flow behind it. If the website is connected directly to the editorial system, every additional channel costs its own connection, with all the consequences for load, coupling and operations. If there is a clean layering between editorial work and delivery, it costs one integration against an existing interface.

The decisive question is therefore not just: Which editorial system do we use? But: What does the data flow look like that brings our content into all the channels we do not know yet?

This article describes the architecture we use for this in customer projects: NovaDB as the leading content repository (content hub), Elasticsearch as the delivery index and a content API as the shared access point for all channels. It also describes when this effort does not pay off.

The path of a piece of content consists of three stages: InBound captures changes from the source systems and transfers them into the unified document model of NovaDB, OutBound builds the delivery index from it, and delivery makes the content available to the channels. All three are deliberately operated, tested and accepted independently of each other.

1. InBound: capturing changes without losing them

Editorial systems report changes via webhook: publication, update, unpublishing, deletion, media update. These messages do not go straight into processing but onto a persistent, replicated message stream. From there, specialized workers fetch the complete document, resolve references and IDs, check link targets, import media and transfer the result into the unified document model of NovaDB.

The most common mistake at this point is to process webhooks directly. Anyone who does this loses events at exactly the moment a service restarts or an import fails. And anyone who adds the event store afterwards writes the import logic a second time.

2. OutBound: building delivery without burdening the editorial team

After every successful write, a follow-up event is published. The OutBound workers read the document through the NovaDB API, map it to an indexable search document with full text, metadata, facets, autocomplete fields and SEO path, and write it to Elasticsearch.

What matters is what this stage does not know. It knows no source systems, only a document ID and the way to NovaDB. This deliberate omission is the reason why connecting an additional source system later costs a new InBound pipeline and nothing else.

3. Delivery: making changes visible within seconds

The website reads from the index and keeps a local cache. A dedicated background service listens to the indexing events and selectively discards exactly the affected cache entries. Editorial changes become visible within seconds, without flushing caches across the board or restarting applications.

Flushing the whole cache is the solution that works in the first week of a project and no longer works in the first load case. A restart after every release is not an operating strategy.

Splitting into InBound and OutBound initially looks like additional effort, but it pays off in four places, and each of them has a price when it is missing.

• Outages stay harmless. If a downstream service is briefly unavailable, no events are lost. They are processed as soon as the service is back. Without this property, every outage becomes a manual re-import of unclear scope.
• Errors can be located. An import problem is an import problem, an index problem is an index problem. Anyone who has debugged a search indexing process that also contained import logic knows the difference in time spent.
• Delivery is decoupled from editorial work. Load peaks on the website do not reach the editorial system. This allows the website to scale without scaling the editorial licenses or the infrastructure of the editorial system along with it.
• Source systems are interchangeable. Whether the content comes from a headless CMS, another third-party system or directly from NovaDB is irrelevant for delivery. Delivery, search, caching and frontend remain untouched by every extension.

A content hub is a leading content repository that holds not only editorial articles but everything that makes up a page: teasers, forms, banners, navigations and page modules as channel-neutral document types.

So far, the data flow has described editorial content. A real website, however, consists of much more: curated teasers, newsletter and contact forms, notice banners, campaign elements, navigations, landing page modules and legal texts. These are exactly the elements that classic editorial systems rarely provide for.

In practice, they therefore end up in one of three places, and none of them holds up in the long run:

• Hard-wired in the frontend. Every change becomes a deployment, and the editorial team cannot act on its own.
• In a second small system or a configuration file. This creates a second maintenance process, a second permission model and a second state of updates.
• In the page templates of the source system. The least conspicuous and at the same time the most expensive variant.

The third case deserves special attention because it undermines the argument of the previous section. If the page composition sits in the templates of the editorial system, the article source can be exchanged, but the page cannot. The interchangeability of source systems then exists only on paper, and it becomes apparent exactly when a replacement is due.

We therefore model these elements as their own document types in NovaDB. They pass through the same OutBound path, sit in the same index and are reachable through the same access point as editorial content. This turns the leading content repository into a content hub for everything that makes up a page, not just for its body text.

The gain is immediate:

• Teaser strips and campaign elements can be checked through the same preview as articles.
• Form definitions are subject to the same schema validation. Required fields and consent texts are thus technically verifiable instead of organizationally agreed.
• Targeted cache invalidation also applies to navigation and teasers. Rebuilding a page does not require a restart.
• Permissions, approvals and traceability apply uniformly and are not separated by content type.

One distinction is crucial here and is regularly overlooked in projects: the hub should hold the channel-neutral module, not the rendered website fragment. A teaser is a curated reference with intent and order, not a finished HTML block. A form is a definition made of fields, validation rules and consent text, not a website widget. Where these modules appear on which page is resolved by the respective channel.

Anyone who writes website layout into the hub instead ties it back to exactly one channel and thereby loses the advantage for which the decoupling was built.

The runtime remains unchanged: the hub describes a form, it does not process submissions. Submitting, spam protection, double opt-in and consent logging remain the responsibility of the channel or a dedicated service.

A content hub bundles content in one document model, but maintenance stays with the tool that fits each content type. The obvious conclusion that maintenance should also take place in one place is usually wrong.

Content types do not differ in detail but in process. Technical documentation depends on modularization, variant control, validation against a schema and a translation process. Product data depends on classification, attribute inheritance and channel-specific output. Web content depends on campaign planning, scheduling, preview and fast publishing. These processes have little in common, and neither do the tools that support them well.

Anyone who forces all three into one system ends up with a system in which two out of three editorial teams work against their tool. The result is easy to observe in projects: shadow processes in Excel and Word, approvals by email and tickets to IT for changes that an editorial team should be able to make itself.

A decoupled data flow resolves this conflict of goals. Each content type stays in the system in which it can be maintained best: technical documentation in the editorial system for TechDoc, product data in the PIM, web content and page modules in NovaDB. Standardization happens in the document model, not in the tool. For delivery and for all connected channels, the origin is irrelevant.

The question in selection projects is therefore no longer which system can do the most, but which editorial team works with which process. These are two very different questions, and only the second can be answered reliably.

Two caveats belong here. Every additional source system costs an InBound pipeline, a mapping into the shared document model and operational responsibility. The architecture makes the choice possible, not free. And consolidating on one system remains a legitimate decision. It is then just a decision and not a technical requirement.

The real gain lies in reversibility: the choice is made per content type and can be corrected per content type. Nobody commits to a single procurement for all content for years.

Two separate indices resolve a conflict that is regularly considered too late during design: editors want to see drafts, end users must not see them.

A preview index contains the current editorial state, a live index contains published content only. Saving a draft writes only to the preview index, and only approval writes to both. Unpublishing removes the document from the live index but keeps it as a draft in the preview.

Editors thus get a reliable preview through exactly the same delivery path that end users go through. Preview and live differ only in the index, not in the rendering logic. Deviations between the preview and the published state are ruled out by design.

Because teasers, banners and page modules also live in the hub, this applies not only to individual articles. A rebuilt teaser strip or a changed campaign notice can be checked completely before it goes live. In setups where these elements sit outside the editorial system, this is exactly what is not possible.

If this point is overlooked, it shows up during acceptance. Retrofitting then usually creates a second rendering path alongside the existing delivery. Two rendering paths drift apart permanently, and the maintenance effort for that exceeds the one-time cost of the second index many times over.

A content API is the lean interface in front of the delivery index through which every channel, not just the website, retrieves content.

So far, the data flow has described a website. The architecture becomes interesting at the point where you stop thinking of it as a website architecture.

The delivery index already contains everything a channel needs: prepared content, resolved references, media URLs, metadata and facets as well as the channel-neutral modules from the hub, in a uniform structure that is independent of the source. All that is missing is a defined access point. That is why we put a lean content API in front of the index, which delivers documents through stable addressing and explicitly distinguishes between the live and the preview state.

This fundamentally shifts the picture:

• The website is just one consumer. It no longer has a special status but uses the same access point as every other channel.
• New channels are integrations, not projects. Apps, newsletter flows, partner and syndication offerings, microsites, landing pages, kiosks or internal applications access the same source without the content pipeline having to be extended.
• Editorial preview works across channels. Because the preview runs through the same mechanism, it can be offered in every connected channel, not just on the website.
• Governance stays in one place. Access protection, rate limiting, versioning and monitoring sit in the API, not scattered across the consumers.

This turns a website architecture into a content platform. Not as a later rebuild, but as a by-product of clean layering. The guaranteed document structure from schema validation is not a formality here but the prerequisite for several channels being able to rely on the same interface at all.

The decoupled architecture delivers its benefits especially when an editorial system is to be replaced.

Because the consumers work against a unified content model and not against a specific editorial system, the old and the new source system can run in parallel. Content areas move in waves, and each wave can be accepted and rolled back individually. There is no cutover date on which everything has to work at the same time, and no feature freeze during the migration.

For the connected channels, the change of source system is ideally not noticeable at all.

A project plan for this path is described in our article Practical project plan for replacing CMS and editorial systems.

Decoupled delivery with an index and a content API is not a recommendation for every project. It costs additional components, additional operations and additional skills in the team.

We do not recommend it if all of the following points apply:

• There is exactly one output channel, and no further one is foreseeable.
• The change frequency is low, and delivery within minutes is sufficient.
• The editorial team and the website sit in the same area of responsibility and the same operating model.
• Replacing the editorial system is not under discussion.

In this case, direct access with an upstream cache is the economically right decision. As soon as one of these points tips, however, and the channel question usually tips first, the calculation shifts significantly.

In practice, four expansion stages emerge:

Which stage makes sense depends on:

• number of current and planned output channels
• required timeliness of editorial changes
• load and availability requirements of the portal
• number and replacement likelihood of the source systems
• number, independence and process differences of the editorial teams involved
• requirements for editorial preview and approval
• planned use of the content by AI and assistant systems

A content data flow is not a side issue of choosing an editorial system. It is the structure that determines operational stability, migration capability and speed of further development.

The principles described here can be applied independently of the specific system landscape: event-driven decoupling, persistent event processing, a leading content repository (content hub), a separate delivery index, separate preview and live states, schema validation at both ends and a content API as the shared access point.

They are the reason why, in our projects, connecting a further source system remains an extension and not a rebuild. And why an additional output channel is an integration rather than a project.

Certainty in decisions instead of retrofitting

The layering of a content data flow is a decision that can only be corrected later with considerable effort. It is all the more important to make it early and on solid ground.

Drawing on projects in web systems and portals, in product communication and in technical documentation, we support you in

• making the current coupling between editorial system and channels visible
• determining the appropriate expansion stage based on your channel and load requirements
• assessing the effort, operational consequences and risks of each stage transparently
• determining, per content type, the maintenance system that fits the actual editorial process
• bringing teasers, forms and page modules back from the frontend into editorial control
• planning the replacement of a source system as a wave-by-wave effort without a cutover date
• structuring content so that AI and assistant systems can use it without a second preparation step

Are you considering replacing an editorial system or planning additional output channels, and wondering what the data flow behind it should look like? Talk to us. We are happy to look at your system landscape.