Dispatcher Deep Dive

Caching, Security, and Performance in Adobe Experience Manager

In the previous article, we explored how HTL transforms prepared data into the HTML returned to the browser. But generating HTML is only part of building a high-performance AEM application.

Imagine thousands of visitors requesting the same page every minute. Even with efficient Sling Models, OSGi Services, and HTL templates, repeatedly rendering identical content would waste valuable server resources.

That's where Dispatcher comes in.

More than just a cache, Dispatcher acts as the front door to AEM, improving performance, protecting Publish instances, and reducing unnecessary rendering. In this article, we'll explore how Dispatcher works, why it's critical in enterprise deployments, and the practices that keep high-traffic AEM websites fast and secure.

Reading time: 10–12 min

AEM Cloud Master Series

This article is Part 7 of a 10-part series designed to help frontend engineers and AEM developers understand Adobe Experience Manager from architecture to production deployment.

Series Roadmap

✓ Part 1 — Understanding Adobe Experience Manager Architecture

✓ Part 2 — The Complete AEM Request Lifecycle

✓ Part 3 — Inside Apache Sling

✓ Part 4 — Sling Models & Dependency Injection

✓ Part 5 — OSGi Services Explained

✓ Part 6 — HTL Explained

✓ Part 7 — Dispatcher Deep Dive (Current)

Part 8 — Building Enterprise Components in AEM

Part 9 — React + Adobe AEM Cloud Service

Part 10 — From Development to Production

In this article, we'll explore how Dispatcher improves performance, protects AEM Publish instances, and helps enterprise websites scale through intelligent caching and request filtering.

Why Dispatcher Exists

Imagine an enterprise website that receives 500,000 page requests every hour.

If every request reached AEM Publish, the servers would spend most of their time generating pages that had already been rendered before.

That approach doesn't scale.

Instead, AEM introduces Dispatcher between visitors and Publish.

Its goal is simple:

Serve as many requests as possible without asking AEM to render the page again.

Where Dispatcher Fits

By now you've seen the overall request lifecycle.

Let's focus on the front half of that journey.

Every public request typically follows this path.

Notice that Dispatcher sits in front of Publish, making it the first AEM-controlled layer that receives traffic after the CDN.

More Than a Cache

Many developers describe Dispatcher as "AEM's cache."

That's true, but it's only part of the story.

Dispatcher has three primary responsibilities.

Cache rendered pages

If a page has already been generated, Dispatcher can return the cached HTML immediately.

No Java code executes.

No Sling Models run.

No HTL templates render.

The visitor receives the page much faster.

Protect Publish

Not every request should reach AEM.

Dispatcher evaluates incoming requests and blocks those that shouldn't be forwarded.

Examples include:

• unauthorized paths,

• administrative URLs,

• malformed requests,

• unwanted HTTP methods.

This reduces unnecessary traffic and helps protect Publish from abuse.

Reduce Server Load

Every cached response is one less request that Publish has to process.

Instead of generating the same page thousands of times, AEM renders it once, and Dispatcher serves that cached version until it changes.

For high-traffic sites, this dramatically improves scalability.

Cache Hit vs Cache Miss

Every request reaching Dispatcher follows one of two paths.

This is one of the most important concepts to understand.

A Cache Hit means the visitor receives a previously generated page.

A Cache Miss means Publish must generate the page before Dispatcher can cache it.

Why Cache Hits Matter

Imagine a homepage that receives 100,000 visitors today.

Without caching:

100,000 Requests

↓

100,000 Page Renders

With Dispatcher:

100,000 Requests

↓

1 Render

↓

99,999 Cached Responses

The difference is enormous.

That's why caching is considered one of the biggest performance optimizations in AEM.

Dispatcher is only one layer in Adobe's delivery architecture. Modern AEM Cloud Service deployments combine Adobe CDN, Dispatcher, and AEM Publish to maximize performance while minimizing unnecessary rendering.

Although both the CDN and Dispatcher cache content, they operate at different layers of the request pipeline and serve different purposes.

Although both cache content, they operate at different layers.

Think of it as multiple opportunities to avoid rendering.

The earlier a request is answered, the less work AEM has to perform.

A Real Production Example

Imagine a visitor opens:

/products/surface-laptop.html

The request follows this sequence.

In the ideal scenario, Publish renders the page only once.

Every future visitor receives the cached version until the content changes.

Mental Model

Think of Dispatcher as the receptionist in a large office building.

Most visitors ask common questions.

Instead of interrupting the engineers every time, the receptionist answers those questions directly.

Only requests requiring new work are forwarded to the engineering team.

Dispatcher works the same way.

It serves cached responses whenever possible and forwards only the requests that genuinely require AEM to generate new content.

How Dispatcher Decides What to Do

In the previous articles, we explored what happens after a request reaches AEM Publish. We followed the request through Sling, Sling Models, OSGi Services, and HTL until the final HTML was generated.

Dispatcher sits before all of that.

Its first responsibility is deciding whether the request should ever reach Publish in the first place.

Every incoming request goes through a series of checks before any rendering begins.

Only requests that pass the security rules and aren't already cached continue to Publish. Everything else is either blocked or served directly from the cache.

Request Filtering

Caching is only one responsibility of Dispatcher.

Equally important is protecting the Publish environment.

Every request is evaluated against a set of filtering rules before it's forwarded.

Typical rules include:

• Allow only supported HTTP methods

• Block administrative URLs

• Restrict access to internal paths

• Prevent direct access to sensitive resources

• Reject malformed requests

For example, a request to:

/system/console

should never reach a public Publish instance.

Dispatcher blocks the request immediately, reducing unnecessary traffic and preventing access to administrative functionality.

Think of Dispatcher as the security guard standing at the entrance of your application. Visitors who don't meet the rules never enter the building.

Understanding the Cache Structure

When Dispatcher caches a page, it doesn't store it inside memory like many application caches.

Instead, it stores the rendered response on the file system.

A simplified cache structure might look like this:

/cache

├── content
│   ├── products
│   │   ├── laptop.html
│   │   ├── tablet.html
│   │   └── monitor.html
│   └── about
│       └── index.html

The next time someone requests the same page, Dispatcher can serve the cached HTML directly from disk without contacting Publish.

This is one reason Dispatcher performs so well under heavy traffic.

What Happens When Content Changes?

Caching introduces an important question.

If a page is cached, how do visitors see updated content after an author publishes changes?

The answer is cache invalidation.

Publishing content doesn't automatically regenerate every cached page.

Instead, Dispatcher removes the outdated cached version.

The next request follows this sequence:

Notice what happens.

Dispatcher doesn't proactively rebuild the cache.

It simply removes the outdated file.

The first visitor after publication causes Publish to generate a fresh version, which Dispatcher stores for future requests.

This strategy keeps cache management simple while ensuring visitors eventually receive the latest content.

Cache Invalidation vs Cache Refresh

These terms are often confused, but they describe different actions.

In most AEM deployments, Dispatcher performs invalidation.

The next request naturally refreshes the cache.

Understanding this distinction helps explain why the first request after publishing is often slightly slower than subsequent requests.

A Production Example

Imagine your marketing team updates the homepage during a product launch.

Immediately after publishing:

• The previous cached homepage is invalidated.

• The next visitor reaches Publish.

• Publish renders the updated homepage.

• Dispatcher stores the new version.

• Every following visitor receives the updated cached page.

Even if millions of users visit later that day, Publish only needs to generate the page once after the cache has been invalidated.

This approach is one of the reasons AEM can support large enterprise websites without requiring every request to be processed by the application itself.

Security: Dispatcher's Other Job

Most developers first encounter Dispatcher because of caching.

But in production environments, its security role is just as important.

Every request from the internet reaches Dispatcher before it reaches your AEM Publish instance. That makes Dispatcher the first line of defense for your application.

Rather than allowing every request through, Dispatcher evaluates each one against a set of predefined rules.

If a request violates those rules, it's rejected before AEM ever processes it.

This protects Publish from unnecessary traffic while reducing the application's attack surface.

Why Publish Should Never Be Exposed

One of the fundamental principles of AEM architecture is that visitors should never communicate directly with the Publish instance.

The recommended production architecture looks like this:

Without Dispatcher, every visitor would communicate directly with Publish.

That means:

• every request consumes server resources,

• malicious requests reach AEM,

• administrative paths become harder to protect,

• caching opportunities are lost.

Dispatcher acts as a protective layer, ensuring only legitimate requests reach the application.

Common Requests Dispatcher Blocks

A well-configured Dispatcher prevents many unnecessary requests from reaching Publish.

Examples include:

• Administrative consoles

• CRXDE Lite

• System Console

• Package Manager

• Invalid HTTP methods

• Internal system paths

• Suspicious URL patterns

For example, requests such as:

/system/console

/crx/de

/crx/packmgr

should never be accessible from the public internet.

Those requests are stopped immediately by Dispatcher.

Even though Publish may also enforce permissions, blocking the request earlier is both faster and more secure.

Performance and Security Work Together

Caching and security aren't independent features.

They complement one another.

A request that can be served from cache avoids unnecessary processing.

A request that shouldn't exist is blocked before it consumes application resources.

The result is a faster and more resilient platform.

Notice that filtering happens before caching.

Only valid requests continue through the rest of the pipeline.

Common Dispatcher Mistakes

Dispatcher is extremely powerful, but small configuration mistakes can have a significant impact.

Caching Personalized Content

Not every page should be cached.

Suppose a page displays:

• the current user's name,

• account information,

• shopping cart contents,

• personalized recommendations.

Serving the same cached HTML to every visitor would produce incorrect results and could expose private information.

A good caching strategy distinguishes between:

• public content,

• personalized content,

• dynamic requests.

Overly Aggressive Cache Rules

Sometimes teams cache everything in an attempt to maximize performance.

The downside is that recently published content may appear outdated because the cache isn't invalidated correctly.

Effective caching isn't about caching the most pages.

It's about caching the right pages.

Weak Filter Rules

A permissive Dispatcher configuration increases the number of requests reaching Publish.

That not only affects security but also increases the workload on the application.

A production configuration should allow only the requests the website genuinely needs.

Everything else should be rejected as early as possible.

Production Insights

One lesson you'll quickly learn on enterprise AEM projects is that performance issues aren't always caused by Java code.

Sometimes the application itself is working perfectly.

The real problem is a low cache hit ratio.

If most requests bypass Dispatcher and reach Publish, you'll notice:

• higher CPU usage,

• slower response times,

• increased infrastructure costs.

That's why one of the first metrics many operations teams monitor is cache effectiveness.

A healthy Dispatcher configuration means most visitors receive cached responses, while Publish focuses only on requests that genuinely require rendering.

Enterprise Insight

One of the most common misconceptions among developers new to AEM is assuming that slow page performance is always caused by inefficient Java code or complex Sling Models.

In reality, experienced AEM teams often begin by checking cache effectiveness. If most requests bypass Dispatcher and reach Publish, even a well-designed application will struggle under heavy traffic.

Improving cache hit ratios frequently delivers larger performance gains than optimizing component code.

Dispatcher Best Practices Checklist

Before deploying an AEM application, it's worth reviewing a few key questions:

• Are public pages being cached?

• Are personalized pages excluded from caching?

• Are sensitive paths blocked?

• Are only required HTTP methods allowed?

• Is cache invalidation working after content publication?

• Is Publish inaccessible from the public internet?

• Is the cache hit ratio being monitored?

These checks are simple, but they often make the difference between an application that performs well in production and one that struggles under load.

Final Thoughts

Dispatcher is much more than a performance optimization.

It's an architectural component that sits between your users and your application, balancing speed, scalability, and security.

Earlier in this series, we focused on what happens inside AEM once a request reaches Publish. Dispatcher reminds us that good architecture also considers what should happen before a request reaches the application.

When configured correctly, Dispatcher allows Publish to spend its time rendering new content instead of repeatedly serving the same pages or processing unnecessary requests.

For enterprise AEM deployments, that separation is one of the keys to building applications that remain fast, secure, and reliable as traffic continues to grow.

Continue Reading

So far in this series, we've focused on understanding AEM's architecture, request lifecycle, rendering pipeline, and the technologies that work together to generate HTML. Dispatcher showed us that performance and security begin long before a request reaches Sling or HTL.

In the next article, we'll move back inside the application and explore how enterprise AEM components are designed. We'll cover component architecture, dialogs, authoring, reusability, and the design patterns that help teams build maintainable component libraries for large-scale projects.

Next: Part 8 — Building Enterprise Components in Adobe AEM

This article explained how requests are accelerated and protected before they reach AEM. In the next article, we'll move inside the application again and explore how enterprise-grade components are designed, authored, and reused across large AEM implementations.