CDN purge race condition with publish activation

[NamitaDu]

In AEM as a Cloud Service with Adobe-managed Akamai, I’m triggering a CDN purge for specific paths right after activating content to publish.
Occasionally, users get 404s or stale content for a few seconds to minutes, which suggests a race condition where the CDN purge happens before the newly published content is fully available on all publish instances.

What’s the best practice to ensure that a purge request to the CDN happens only after all publish instances are serving the updated content?

[PavanGaddam]

It is always a best practice to use the Cache-Control header configuration for CDN caching strategy than depending on the manual CDN cache purge. For the time critical resources on your site, you can use manual CDN cache purging. You may get a stale content for some time depending on the max-age value defined for Cache-Control header in dispatcher configurations and the /gracePeriod defined in dispatcher. 

BTW, the OOTB CDN in AEM CS is  Fastly, not Akamai.

[SantoshSai · Accepted solution]

Hi @NamitaDu,

Agree with @PavanGaddam and yes he is right it's a Fastly.

this is a sequencing issue. In AEM as a Cloud Service, content activation to publish is asynchronous across all publish instances. If you trigger a Fastly purge immediately after activation, the CDN can request the new asset/page before it’s available everywhere, resulting in 404s or stale content.

Best practice:

1. Wait for replication success events

   • Use the AEM ReplicationEventListener (for classic replication) or the Sling Job/Workflow completion listener for CF/Assets.

   • This ensures you only act after the content has been persisted on all publish nodes.

2. Add a short buffer delay

   • Even after the event fires, add a few seconds (e.g., 2–5s) to allow all publishers in the cluster to serve the new content.

3. Purge via Adobe’s Fastly API

   • Use the aio-cli or direct HTTP call to POST /service/{id}/purge/{path} with your Adobe-provided Fastly service ID and API token.

   • Reference: https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/con...

References:

• https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/con...

• https://www.fastly.com/documentation/reference/api/purging/

[PavanGaddam]

The CDN/Dispatcher should always forward cache-miss requests to Publish. Only in the case of a genuinely unavailable resource (not yet replicated, or with authoring/publishing delays/problems) should a 404 occur.

For most practical AEM Cloud/Dispatcher/CDN setups with correct config, you should not see user-facing 404s simply because of a cache purge, unless covering that brief moment of genuine origin unavailability.

The "race condition" is partially valid for high-volume sites only if Publish is not ready or slow to serve newly activated content, but not a default/expected behavior. With correct configuration and origin health, the system should always serve the page either from cache or from origin, and only a true "unpublish" or a slow activation can lead to 404.

A 404 occurring in this situation is only possible if -

• The page genuinely isn't available yet on Publish (not yet replicated, in the process of activation, or has errors).
• There's misconfiguration causing Publish not to correctly serve fresh requests for just-activated content.
• Dispatcher or CDN is not configured to properly forward cache misses to the origin.

If everything is working as designed:

• No cached page on CDN/Dispatcher → Forward to Publish → Publish serves the page and caches it.
• 404 should be rare and only reflect a temporary "not yet published" state.

Refer to this WKND Github repository for the caching best practices.

[SantoshSai]

@PavanGaddam 

Thanks for expanding on this - you’re absolutely right that under a properly configured AEMaaCS + Dispatcher + CDN setup, cache misses should always fall back to Publish and a 404 should only occur if the page truly isn’t available yet (unpublished, activation in progress, or origin issue).

The main intention of my note was to highlight that if users are seeing 404s immediately after cache purges, it usually indicates either:

• Publish didn’t have the content available yet, or

• Dispatcher/CDN isn’t fully forwarding misses to origin correctly.

In most healthy configurations, users should never face a transient 404 purely because of cache invalidation.