AEM Architecture

Understand the full AEM architecture - Author, Publish, Dispatcher, and how they work together in enterprise deployments.

Last reviewed: December 2024

·AEM 6.xAEM as a Cloud Service
✅
Quick Understanding: AEM runs on a three-tier architecture: Author (where content is created), Publish (where content is delivered to users), and Dispatcher (the caching/security layer in front of Publish). Content flows from Author -> Publish via Replication.

🔍 What Is It?

AEM's architecture separates content creation from content delivery:

  • →Author Instance - Where content editors, marketers, and developers work. Not accessible to the public.
  • →Publish Instance - Serves the live website to end users. Receives content from Author via replication.
  • →Dispatcher - Apache HTTP Server module that caches Publish output and acts as a security filter.
  • →CDN (optional but common) - Sits in front of Dispatcher for global edge caching.

This separation ensures that authoring activities (which can be resource-intensive) don't impact the performance of the live website.

🎯 Why Do We Need It?

Separation of concerns:

  • →Authors can work on content without affecting live site performance
  • →Publish instances can be scaled independently based on traffic
  • →Dispatcher caching means AEM rarely needs to render the same page twice
  • →Security: Author is never exposed to the internet

High availability:

  • →Multiple Publish instances can run behind a load balancer
  • →If one Publish instance fails, others continue serving
  • →Dispatcher serves cached content even if Publish is temporarily down

🏗️ What Happens in Real Projects?

In a typical enterprise deployment:

  1. Content editors work in the Author instance (usually internal network only)
  2. When ready, they click "Publish" - AEM replicates the content to Publish
  3. Publish receives the content and can now render it
  4. Dispatcher caches the rendered HTML on first request
  5. Subsequent requests are served from Dispatcher cache (fast!)
  6. When content is updated and republished, Dispatcher flushes the cache

Author URL: https://author.mysite.com (internal only)

Publish URL: https://www.mysite.com (via Dispatcher/CDN)

⚙️ How It Works

Replication:

When an author publishes content, AEM's Replication Agent sends the content from Author to Publish. This is a push model - Author pushes to Publish.

Reverse Replication:

When users submit forms or generate content on Publish (like comments), Reverse Replication sends that data back to Author.

Oak Repository:

Both Author and Publish have their own Oak (JCR) repository. They're separate - content must be explicitly replicated between them.

Sling Request Processing:

  1. Request arrives at Dispatcher
  2. Dispatcher checks cache -> cache hit: serve file
  3. Cache miss: forward to Publish
  4. Publish runs Sling URL decomposition
  5. Sling finds the right script (HTL/component)
  6. Script renders HTML
  7. Dispatcher caches the response

AEM Dispatcher Architecture — Request Flow

👤

User Browser

HTTP Request

request
cache hit ↩
🌐

CDN

Edge Cache

request
cache hit ↩
🛡️

Dispatcher

Cache + Filter

request
cache hit ↩
⚡

AEM Publish

Render Engine

Cache Miss → Request passes through all layers
Cache Hit → Response returned from nearest cache

💻 Example

AEM Request Processing Flow — How a page request flows through the AEM stack.

text
User Request: GET /en/home.html

1. CDN (Fastly/Akamai)
   -> Cache hit? Serve from CDN edge. Done.
   -> Cache miss? Forward to Dispatcher.

2. Dispatcher (Apache + mod_dispatcher)
   -> Check /var/cache/dispatcher/en/home.html
   -> Cache hit? Serve file. Done.
   -> Cache miss? Forward to AEM Publish.

3. AEM Publish (Sling + Oak)
   -> URL decomposition: /en/home.html
   -> Resource: /content/mysite/en/home
   -> Selector: none, Extension: html
   -> Find rendering script via sling:resourceType
   -> Execute HTL template + Sling Models
   -> Return rendered HTML

4. Dispatcher caches the response
5. CDN caches the response
6. User receives the page

🤔 Common Confusions

❓ Can users access the Author instance directly?

No. The Author instance should never be publicly accessible. It's protected behind a corporate firewall or VPN. Only content editors, developers, and admins should have access to Author.

❓ What happens if Publish is down but Dispatcher cache exists?

Dispatcher can serve stale cached content while Publish recovers. This is called "grace mode" and is configurable. It's one of the key resilience benefits of the Dispatcher.

🚨 Common Production Issues

Content published on Author not appearing on the live site - replication agent is failing. Check the replication agent queue in AEM Author.

Author and Publish showing different content - replication backlog. Check /etc/replication/agents.author for queue status.

High load on Publish - Dispatcher cache is not working. Check cache hit ratio and flush configuration.

AEM Cloud Service page published successfully but users still see old content - check CDN TTL, Dispatcher invalidation, referenced Experience Fragments or Content Fragments, and whether all dependencies were published.

Only one environment is failing - compare Cloud Manager deployment version, OSGi run mode config, content package state, and CDN/Dispatcher rules between Dev, Stage, and Production.

✅ Best Practices

Never expose Author directly to the internet - always put it behind a VPN or firewall.

Run multiple Publish instances behind a load balancer for high availability.

Monitor replication queue length - a growing queue means content isn't reaching Publish.

Use a CDN in front of Dispatcher for global sites.

Define an operational runbook that separates content publication issues, Dispatcher/CDN cache issues, application errors, and Cloud Manager deployment failures.

For AEM as a Cloud Service, use Cloud Manager logs and Developer Console-style diagnostics instead of relying on direct server access.

🏛️ Architect's Note

Senior Architect's Perspective

The Author-Publish-Dispatcher architecture is AEM's greatest strength for enterprise use. It provides a clear governance model, high performance through caching, and security through separation.

For AEM as a Cloud Service: The same architecture applies but Adobe manages all the infrastructure. You don't configure Publish instances or Dispatcher servers manually - Cloud Manager handles it. The CDN (Fastly) is built in.

💬 Frequently Asked Questions

How many Publish instances does a typical enterprise AEM site have?

It depends on traffic. Small sites might have 2 Publish instances (for redundancy). High-traffic sites might have 4-8. In AEM as a Cloud Service, scaling is automatic - Adobe manages the number of instances based on load.

What is the difference between AEM Author and AEM Publish in terms of features?

Author has the full authoring UI (Sites console, Assets console, page editor, etc.). Publish only serves content - it has no authoring UI. Some OSGi services run only on Author (like workflow engines) and others only on Publish (like Dispatcher flush agents).

🎯 Key Takeaways

1Three tiers: Author (create) -> Publish (deliver) -> Dispatcher (cache + security)
2Content flows Author -> Publish via Replication
3Dispatcher caches rendered HTML - most requests never hit AEM
4Author is never public-facing - always behind firewall/VPN
5Multiple Publish instances provide high availability

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these AEM references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages

SplashRide AEM learning path

Browse the full AEM topic collection and learning order on SplashRide.

AEM Interview Prep

Practice AEM interview questions and scenario-based answers.

AEM Developer Career Path

This AEM developer career path explains how to become an AEM developer through JCR, Sling, HTL, client libraries, Dispatcher, Cloud Service delivery, project depth, and interview-ready enterprise implementation skills.

Drupal Developer Career Path

A practical route through Drupal content modeling, site building, theming, modules, configuration management, APIs, performance, deployment discipline, and interview preparation.

AEM Dispatcher

Understand the AEM Dispatcher — the caching and security layer that sits in front of your publish instance. Learn how it works, how to configure it, and why it breaks in production.

AEM as a Cloud Service

Understand what AEM as a Cloud Service is, how it differs from AEM 6.5, and what you need to know to develop and deploy on the cloud platform.