Dispatcher Config and Caching

The layers

A request passes through several caches, each with its own rules. Knowing which one is serving stale content is most of debugging:

1. Browser cache — governed by Cache-Control on the response.
2. CDN — Adobe's managed CDN, also governed by Cache-Control, with its own purge API.
3. Dispatcher — file cache on disk, invalidated by .stat files on publish.
4. AEM — renders, and has its own internal caches.

The Cloud Service dispatcher structure

Your project's dispatcher/src follows a prescribed, validated layout:

dispatcher/src/
  conf.d/
    available_vhosts/       # virtual host definitions
    enabled_vhosts/         # symlinks to the ones in use
    rewrites/               # rewrite rules
    variables/
  conf.dispatcher.d/
    available_farms/        # farm definitions
    enabled_farms/          # symlinks to the ones in use
    cache/                  # cache rules and TTL settings
    filters/                # the security filters
    clientheaders/
    renders/
    virtualhosts/

The available_ / enabled_ pairing lets you keep configuration in the repository without activating it. Files under enabled_ are symlinks — a real detail that catches people out on Windows.

Adobe owns some of these files and you own others. The update_maven script refreshes Adobe's baseline when they revise it, which is why keeping your customisations in the designated custom files matters.

TTLs

On Cloud Service, cache lifetime is driven by Cache-Control headers rather than solely by Dispatcher configuration. You set them per content type:

<LocationMatch "^/content/.*\.html$">
  Header set Cache-Control "max-age=300,stale-while-revalidate=60"
</LocationMatch>

<LocationMatch "^/etc\.clientlibs/.*">
  Header set Cache-Control "max-age=31536000,immutable"
</LocationMatch>

Reasonable defaults:

• Versioned clientlibs and assets — very long (a year), immutable. The URL changes when the content does, so it is safe.
• HTML pages — short, minutes. Long enough to absorb traffic spikes, short enough that publishing feels responsive.
• Personalised or authenticated responses — private or no-store. Never let a shared cache hold them.

stale-while-revalidate is worth knowing: the cache serves slightly stale content while fetching a fresh copy in the background, so a visitor never waits for a revalidation.

Invalidation and purging

• Dispatcher — publishing triggers a flush, which touches .stat files (day 6). This is automatic.
• CDN — not automatically purged by publishing. Content ages out by TTL, or you purge explicitly.

Adobe provides a purge API for the CDN, configured through a config pipeline. Use it for genuine urgency — a legal correction, a wrong price, an incident. It is not a substitute for sensible TTLs: purging routinely means your TTLs are wrong.

Migrating an existing Dispatcher config

Moving from AMS or on-premise, an existing configuration will not transfer as-is: Cloud Service prescribes the structure and validates it. Adobe's Dispatcher Converter (part of the modernisation tooling, day 40) transforms a legacy configuration into the Cloud Service shape, which you then review and validate with bin/validate.sh.