Architecture
EDS separates content from code. Content is authored in AEM, SharePoint, or Google Drive and stored in the Content Bus. Code (blocks, scripts, styles) lives in GitHub. The Delivery Pipeline combines both at request time and serves the result through the CDN. Each side can be deployed independently, which is why both content publishes and code pushes propagate in seconds.
High-level flow
Content Bus
The Content Bus is the central content store. When an author publishes from AEM, SharePoint, or Google Drive, the content is normalised into a simple HTML + metadata representation and stored in the Content Bus. Two important properties:
- Source-agnostic shape - every authoring source converges on the same structure
before it reaches the pipeline. A
heroblock from a Word document and aherocomponent from Universal Editor produce the same intermediate HTML. - Two states per resource - every URL has a preview and a live copy. The preview is what authors see immediately; the live copy only updates when they click Publish.
Delivery Pipeline
The pipeline combines content from the Content Bus with frontend code from GitHub and serves the HTML, scripts, styles, and media through the Edge Delivery origins:
- Content fetch - HTML fragments from the Content Bus
- Code lookup - scripts, styles, and block assets are resolved from the GitHub ref
- Optimisation - HTML minified, images lazy-loaded, CSS / JS inlined where useful
- Caching - aggressive CDN caching with instant purge on publish
Block decoration itself runs in the browser via scripts/aem.js and each block's
decorate(block) function. The pipeline is stateless. There is no server state per
visitor; personalisation happens through the configured experimentation/decisioning
plugin or in the client.
CDN layer
EDS uses Fastly as its built-in CDN (Adobe-managed). You can also bring your own CDN
(Akamai, Cloudflare, etc.) and place it in front of the *.aem.live origin.
Key behaviours:
- Stale-while-revalidate for near-zero latency on cache misses
- Instant purge when content or code changes (push-invalidation)
- Traffic management via the Adobe-managed CDN configuration
- Bot detection and traffic management
URL tiers
| Tier | URL pattern | Purpose |
|---|---|---|
| Preview | https://main--{repo}--{org}.aem.page/ | Author preview, not cached |
| Live | https://main--{repo}--{org}.aem.live/ | Production-ready, cached, used as CDN origin |
| Production | https://www.example.com/ | Custom domain via CDN (Adobe or BYO) |
The legacy hlx.page / hlx.live hostnames are still served and resolve to the same
origin - you'll see both in older repos and tooling.
The branch in the URL matters. main is the default; pushing to a feature branch gives
you https://feature--{repo}--{org}.aem.page/, which is invaluable for review.
push-invalidation
When content or code changes, EDS invalidates the Adobe-managed CDN so the next request
can pick up the new version. With a BYO CDN, configure that CDN's cache keys, TTLs, and
purge automation explicitly; otherwise it may continue serving stale *.aem.live
responses until its own TTL expires.
Where state lives
| State | Where it lives |
|---|---|
| Authored content | AEM repository, SharePoint, or Google Drive |
| Normalised content | Content Bus (Adobe-managed) |
| Frontend code | GitHub repository |
| Cached HTML | CDN edge |
| Visitor session | Browser only (no per-visitor server state) |
| Experimentation assignment | Experimentation/decisioning plugin state and RUM data |
See also
- Authoring models
- Development - GitHub flow and local dev
- Performance - how the pipeline keeps Lighthouse at 100
- Admin API - programmatic preview / publish / purge