Author / publish / dispatcher topology
Purpose: Reference for the standard AEM 6.5 deployment shapes and the responsibilities of each tier.
Who this page is for
| Audience | Why it matters to you |
|---|
| All engineers | The map your requests travel |
The standard production shape
┌──────────┐
Authors ──VPN──▶ │ AUTHOR │ (often 1 primary + cold standby)
└────┬─────┘
│ replication (per publish agent)
┌─────────────┼─────────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│PUBLISH1│ │PUBLISH2│ │PUBLISH3│ (N ≥ 2, stateless-ish, scale for traffic)
└───┬────┘ └───┬────┘ └───┬────┘
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ DISP 1 │ │ DISP 2 │ │ DISP 3 │ (usually 1:1 with publish)
└───┬────┘ └───┬────┘ └───┬────┘
└─────────────┼────────────┘
▼
Load balancer / CDN ──▶ visitors
| Tier | Scaling driver | State |
|---|
| Author | Number of concurrent authors, workflows, DAM processing | THE content source of truth — backup focus |
| Publish | Uncached traffic + invalidation churn | Receives content; rebuildable from author |
| Dispatcher | Raw traffic | Cache files; disposable |
Facts engineers rely on
- Publish instances are independent peers — each has its own repository copy, fed by its own replication agent. No shared DB.
- A user's requests may hit different publishers — never assume instance-local state (sessions, in-memory caches must be soft).
- Author is a single logical instance in 6.5 standard setups (cold standby for failover — an elective topic); it is not horizontally scaled like publish.
- Dispatcher pairs typically stick to one publish (
/renders with failover) — cache consistency per dispatcher is per-publisher.