Parent/Child Dispatcher Cache Flushing and statfileslevel

[AEM_Dan]

I just want to validate what I am seeing.  When cache is invalidated, all child pages under the lowest statfileslevel *and* parent pages are flushed.  So it's really just sibling folders and parent sibling folders that are untouched.

I found this article very helpful to understand statfileslevel. https://medium.com/%40ucgorai/how-statfilelevel-works-in-aem-dispatcher-453fb2fc95ef However, our system is most similar to Case 4 and it's not working like the article describes.

I found when /content/mysite1/news/latest.html is updated everything upstream is invalidated, including home.html and about.html.  Is the article wrong or do I have something misconfigured?  Thank you.

Case 4: statfilelevel = 3 (Highly Granular Invalidation)

1. The .stat file is placed at deeper levels, closer to the actual pages.

/cache/
│── content/
│   │── mysite1/
│   │   │── .stat  ← (Remains unchanged)
│   │   │── home.html ✅ (Cached)
│   │   │── about.html ✅ (Cached)
│   │   │── news/
|   |   |   │── .stat  ← (Invalidates only /content/mysite1/news/)
│   │   │   │── latest.html ❌ (Invalidated)
│   │   │   │── archived.html ❌ (Invalidated)
|   │── mysite2/
|   |   │── .stat (Remains unchanged)
|   |   │── home.html ✅ (Cached)
│── etc/
│   │── .stat  ← (Remains unchanged)
│   │── designs/
│   │   │── site.css ✅ (Cached)

2. Effect:

• If /content/mysite1/news/latest.html is updated, only /cache/content/mysite/news/ is invalidated.

[VishalKa5]

Hi @AEM_Dan ,

I recently tested AEM Dispatcher cache invalidation and found that popular articles about statfileslevel are incorrect about what actually gets invalidated.

The Common Misconception

Many articles claim that with statfileslevel = 3, when you update /content/mysite1/news/latest.html, only the /news/ folder gets invalidated and parent pages like home.html and about.html stay cached.

This is wrong.

What Actually Happens

When Dispatcher invalidates cache, it:

1. Deletes the changed file
2. Updates .stat file timestamps at the configured level
3. Invalidates ALL files older than the .stat file - including parents

Real Behavior with statfileslevel = 3

When /content/mysite1/news/latest.html updates:

/cache/content/mysite1/│── .stat  ← UPDATED│── home.html  ❌ INVALIDATED (older than .stat)│── about.html  ❌ INVALIDATED (older than .stat)│── news/│   │── .stat  ← UPDATED│   │── latest.html  ❌ DELETED│   │── archived.html  ❌ INVALIDATED

What gets invalidated:

• The changed file
• All child pages
• All parent pages up the tree

What stays valid:

• Sibling folders (/mysite2/ when /mysite1/ changes)

Why This Design Makes Sense

Parent pages often display or reference child content:

• Homepage shows "Latest News"
• Navigation menus reflect content structure
• Category pages list child articles

If parents stayed cached when children changed, they'd show stale data. Dispatcher prioritizes correctness over granularity.

What statfileslevel Actually Controls

Misconception: statfileslevel protects parent content from invalidation

Reality: statfileslevel protects sibling content from invalidation

With statfileslevel = 3:

• Changing /mysite1/news/ invalidates all of /mysite1/
• But /mysite2/ stays valid (it's a sibling)

If You Need More Granular Control

1. Custom invalidation rules - Use /invalidateHandler for specific paths only
2. TTL-based caching - Set time-based expiration for stable pages
3. Separate dispatchers - Use different instances for different sections
4. Manual invalidation - Control exactly what gets flushed via custom workflows

Bottom Line

Your configuration isn't broken. Parent pages getting invalidated when child pages change is correct behavior by design.

The articles are misleading - statfileslevel doesn't prevent parent invalidation, it only isolates sibling content trees from each other.

Understanding this is crucial for properly configuring Dispatcher and setting realistic expectations about cache behavior.

Key Point: If you're seeing parent pages invalidate with child pages, that's not a bug - it's a feature that prevents serving stale content.

Thanks,

Vishal

[SantoshSai]

Hi @AEM_Dan,

What you’re describing actually can happen depending on how your Dispatcher rules are set up. The article you linked is great for understanding the concept of statfileslevel, but in real AEM Cloud setups there are a few other factors that determine how widely the cache gets invalidated.

A few things to validate:

1. statfileslevel is relative to the docroot path

statfileslevel = 3 doesn’t literally mean “three folders after /content”.
It means “three folder levels from the cache root (dispatcher cache docroot).”

Example:
If your Apache docroot for Dispatcher is something like:

/mnt/var/www/html/cache/

Then Dispatcher counts from there, not from /content.

If your folder structure looks like:

cache/
  content/
    mysite1/
      news/
         latest.html

Then the levels might be:

/cache         = level 0
/cache/content = level 1
/cache/content/mysite1 = level 2
/cache/content/mysite1/news = level 3  ← stat file here

Depending on your docroot, you might actually be hitting statfiles that are higher up than you think.

This would cause broader invalidation than Case 4 in the article.

2. Check if you have any .stat files placed manually in higher folders

Sometimes projects mistakenly include .stat files in custom Docker images or configs:

cache/content/.stat
cache/.stat

If Dispatcher sees a .stat higher up, that becomes the effective invalidation point.

3. Check your /invalidate rules in dispatcher.any

If you have rules like:

/0000 { /glob "*" /type "allow" }

or you allow invalidation for *.html without filtering by path, Dispatcher might invalidate broader areas.

For example:

/invalidate
  {
    /0001 { /glob "*.html" /type "allow" }
  }

This causes every HTML change anywhere to invalidate all .stat levels - parent pages included.

4. AEM Cloud CDN layer can also trigger broader flushes

On AEM as a Cloud Service, the Fastly layer does not follow the exact same behaviour as on-prem.
CDN purge triggers can be more aggressive depending on:

• Surrogate keys

• Path patterns

• Custom invalidation rules

If your project is using generic surrogate keys like content/*, Fastly will purge higher-level paths too.

5. “Case 4” from the article assumes perfect, isolated folder structures

Real projects rarely match that.
If your path structure under /cache/content/mysite1/ has additional nesting or dynamic rewrite rules, the stat level shifts.

So, in short: If /content/mysite1/news/latest.html is updated, and home.html + about.html (siblings of the parent folder) are also purged, it means your effective statfilelevel directory is higher than expected.

So the article is not “wrong.”
It’s just describing the ideal scenario, not taking into account:

• Dispatcher's actual docroot

• Extra .stat files

• Your project’s /invalidate rules

• AEM Cloud CDN invalidation behaviour