CDN purge race condition with publish activation | Community
Skip to main content
N
NamitaDu
Level 2
August 15, 2025
Solved

CDN purge race condition with publish activation

  • August 15, 2025
  • 2 replies
  • 558 views

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?

Best answer by SantoshSai

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

References:

2 replies

P
Adobe Employee
PavanGaddamAdobe Employee
Adobe Employee
August 15, 2025

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
    Community Advisor
    SantoshSaiCommunity AdvisorAccepted solution
    Community Advisor
    August 15, 2025

    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

    References:

    Santosh Sai
      P
      Adobe Employee
      PavanGaddamAdobe Employee
      Adobe Employee
      August 15, 2025
      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
        Community Advisor
        SantoshSaiCommunity Advisor
        Community Advisor
        August 16, 2025

        @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.

        Santosh Sai
          Terms & ConditionsAccessibility statement

          Loading footer...