AEM Architecture Explained: Author, Publish, Dispatcher
Series: AEM Foundations — Part 2
If there's one concept every AEM developer needs to internalize before writing code, it's the three-tier architecture: Author, Publish, and Dispatcher. Misunderstanding this leads to some of the most common (and confusing) bugs new AEM developers hit — content that "works on author but not on publish," caching issues, or components that behave inconsistently.
The Author Instance
The Author instance is where content authors and developers work. Think of it as the "backstage" environment:
Authors log in, create pages, drag components onto templates, and configure content
Developers deploy code here first to test
It has the full authoring UI: the page editor, component dialogs, the DAM console, workflow tools
It is never exposed directly to end users — it should sit behind your organization's firewall or VPN
Because Author holds the editing tools and unpublished drafts, it's also where content review and approval workflows typically run before anything goes live.
The Publish Instance
The Publish instance is what actually serves content to real visitors. Key differences from Author:
It's a read-optimized copy of content, replicated from Author
It has no authoring UI — it just renders pages
In production, you'll usually run multiple Publish instances behind a load balancer for scalability and redundancy
Content reaches Publish through a process called replication — when an author clicks "Publish" on a page, that content is pushed from Author to one or more Publish instances
This separation exists for a good reason: it keeps your live site fast and stable, since Publish doesn't carry the overhead of the authoring tools, and it means authors can safely draft and preview content without it being visible to the public.
The Dispatcher
The Dispatcher is often the most misunderstood piece for newcomers. It's not a full AEM instance — it's a caching and load-balancing module (technically an Apache HTTP Server module) that sits in front of Publish.
Its main jobs:
Caching rendered HTML pages so Publish doesn't have to regenerate them on every request
Security filtering — blocking requests to sensitive paths, restricting what URL patterns are servable
Load balancing across multiple Publish instances
When someone visits your live AEM site, their request usually hits the Dispatcher first. If a cached version of that page exists and is still valid, Dispatcher serves it directly — Publish never even sees the request. If there's no valid cache, Dispatcher forwards the request to Publish, caches the response, and serves it.
This is why cache invalidation is such a recurring topic in AEM — if Dispatcher is serving a stale cached page after a content update, visitors won't see the change until the cache is cleared or refreshed (we'll cover this in depth in the Architecture & Operations series).
Putting It Together: A Request's Journey
Here's the typical flow when a page is published and then visited:
An author edits a page on Author and clicks Publish
Replication pushes that content to the Publish instance(s)
A visitor requests the page URL
The request hits Dispatcher first
Dispatcher checks its cache — serves the cached file if valid, or forwards to Publish if not
Publish renders the page (using your Java/HTL components) and returns it
Dispatcher caches the response for future requests and serves it to the visitor
Why This Matters Day-to-Day
Once this model clicks, a lot of AEM "mysteries" stop being mysterious:
A page looking wrong on the live site but fine in Author almost always points to a replication or caching issue, not a code bug
Performance problems on a live site are often a Dispatcher caching configuration issue, not a Java/HTL problem
Security reviews frequently focus on Dispatcher rules, since it's your first line of defense against unwanted requests reaching Publish
What's Next
Now that you know how requests flow through AEM's architecture, the next post sets up your actual local development environment using the AEM SDK, so you can start building and testing components on your own machine.
Next in this series: [Setting Up a Local AEM SDK Dev Environment]