CMS Publish Events, Cache, Search, and Rollback

Working case

Editor 47 publishes revision 9 of article 447. The article route updates, but a category card still shows revision 8 and search returns revision 7. A purge request times out, so the publisher cannot tell whether the CDN accepted it. Retrying blindly with a stale payload could even restore an older search document. The repaired workflow records the article ID, new publication revision, status, and affected route dependencies. A worker can retry invalidation under that identity, while each projection checks the current published revision before writing. A reader may briefly see mixed versions, so the team defines an acceptable lag and records it. If revision 9 contains a mistake, publishing approved revision 8 again creates revision 10 as the new public decision rather than pretending the earlier transition never occurred.

Implementation boundary

function applyPublication(current, event, document) {
  if (event.version !== current.version) return document;
  if (document && document.version >= event.version) return document;
  if (current.status !== "publish") return null;
  return { articleId: current.id, version: current.version, title: current.title };
}

const current = { id: 447, version: 9, status: "publish", title: "Cache ownership" };
let searchDocument = applyPublication(current, { version: 9 }, null);
searchDocument = applyPublication(current, { version: 8 }, searchDocument);
console.log(searchDocument);

Commit the CMS publication change and a durable change record in the same persistence boundary when the CMS permits it; otherwise reconcile from a periodic scan of current published revisions. Assign a monotonic publication version per article. Maintain a dependency index from article ID to canonical route, old-path redirects, category cards, related cards, feed segments, and search documents. A worker reads the current version, rebuilds those targets, and invalidates cached responses by exact path or versioned key. Make retries idempotent and keep a dead-letter or repair queue for repeated failure. Unpublishing must remove search and listings as well as the route. Do not rely on a single webhook delivery as the only record of the change; webhooks can be duplicated, delayed, or lost.

Cost and boundaries

One publish event can fan out to D dependent surfaces. Rebuilding only known dependencies costs work proportional to D rather than re-rendering the whole site, but keeping the dependency index correct adds write and audit work. A versioned cache key avoids ambiguous purge completion but retains older objects until expiry. Path purges reduce retained bytes but can fail independently across regions. Search indexing is usually asynchronous, so query results may lag the article route; the service should measure that delay and decide a reasonable budget. A full reconciliation scan over N articles is O(N) and may be scheduled off the request path. Preserve enough event and projection state to diagnose which surface is stale without storing unpublished bodies in a public log.

Failure trace

Deliver publish events for revisions 8, 9, and 10 out of order, then assert every consumer ends at the current published version. Send the same revision twice and verify it does not duplicate a search document or purge job. Fail the CDN purge after the CMS commit and confirm the repair worker can retry; fail the webhook entirely and confirm a revision scan discovers the change. Unpublish the page and check route, cards, search, feed, and sitemap. Rename its path and verify redirects and old caches do not revive an obsolete body. Publish a rollback revision and verify the public version increases even though its approved text comes from an older body. Measure how long each surface remains stale.

Verification

• An older event cannot overwrite a newer public projection.
• Lost webhooks are recoverable by comparing current published revisions.
• Unpublish withdraws the route and each discovery surface.

Practice drill

Build a small publication ledger for article 447. Record revision 8 as public, publish revision 9, then deliver events in the order 9, 8, 9. A search consumer should apply only the current published version. Record affected routes and verify the category card, related card, route, and search document all converge after retries. Simulate a lost webhook and discover revision 10 through a periodic reconciliation pass. Add an unpublish transition and a rollback that republishes approved revision 8 as a new public version. Report last applied version and lag for each projection rather than returning success merely because the CMS save completed.

Decision note

A successful CMS save begins publication; versioned reconciliation makes every public projection catch up and exposes failures.

Common Mistakes

• Equating CMS save success with complete public publication.
• Reapplying an old event payload without checking current revision.
• Purging only the article route while leaving cards and search stale.

Related lessons

CMS Content, Publication, and Preview Boundaries; CMS Public Projections and Route Identity; CMS Draft Preview Authorization and Cache Isolation; CMS Media Variants, Alt Text, and Asset Ownership; HTTP Delivery and Cache Ownership; Content Discovery and Structure; Background Workflow Reliability.

Apply and check

Build Project: CMS Publication Reconciliation and review Web Development: CMS publication contracts.