Content API: an event-driven headless content platform

The problem

The content that describes a museum object lives in at least three systems: the collection management system (the curatorial source of truth), the CMS (editorial and interpretive copy), and the DAMS (images and media). Every channel — website, in-gallery screens, mobile, partner feeds — needs a stitched view of all three, and historically each channel stitched it itself with point-to-point calls.

That shape fails predictably: N sources × M consumers integrations, cache invalidation nobody owns, and every downstream launch blocked on every upstream team.

The architecture: events at the core

The platform inverts the dependency. Source systems don't get called — they emit. Every create, update or unpublish in the CMS, collection system or DAMS lands on an event backbone as a typed domain event (content.updated, object.republished, asset.derived). Consumers subscribe to the events they care about and maintain their own read models.

The public face is a single Content API: one contract for every head, backed by read models that are rebuilt from the event stream rather than assembled per-request from the sources.

Why event-driven, specifically

• Isolation of failure — a slow DAMS never takes the website down; consumers serve their last-known-good read model
• Independent deployability — a new consumer (say, a new gallery interactive) subscribes to existing events; no upstream change requests
• Replayability — read models are disposable; rebuild search or cache from the event history instead of migrating them
• Auditability — 'what changed, when, and who consumed it' is a query over the stream, not forensics

Outcomes

The same content contract now feeds the web estate and exhibition interactives, and new consumers onboard without touching the source systems. [VERIFY] The deeper win is organisational: editorial, curatorial and digital teams ship on their own cadence because the event contract — not a meeting — is the integration point.