Skip to content

SEP-02 - Trigger CloudWatch Cache Invalidation on Publish

Use Case

When a page is published, it triggers a workflow on the Author (typically VT Request To Publish) which goes through several steps, including

  • Activation: update all of the Publisher machines with the updated content.

    • The Publishers in turn send a Dispatcher Flush notification to each of their Dispatcher (cache) machines.

      • Dispatcher Flush updates the timestamp of the .stat file at the top of the site's content tree, which invalidates all of the content below.
      • When a file (page, image, etc). is requested, the Dispatcher compares the timestamp of the cached file to the .stat, and if the .stat is newer (i.o.w. the cached content is out of date, "invalid"), a new rendering is made with a request to a publisher, stored as a file, and sent to the original requestor.
      • We invalidate at the top of the content tree because a new or updated page may be referenced by other pages in the content tree - a typical example is that the new page is added to navigation links in other pages on the site. Invalidating the entire tree allows the other pages to update sooner.

Some of our sites are also cached in AWS CloudFront (CF), a global Content Delivery Network (CDN). CloudFront has a mechanism for cache invalidation.

This Enhancement Proposal is a mechanims to automate CF cache invalidation upon Activation in AEM.

Why this is a problem

Alternatives

  • add a workflow step in AEM to run a command-line or script
  • add to "VT Request To Publish" after "Activate Page" and before "Notify the Requestor"

References