HomeEE · Integrations › Edge-compute patterns ⚡ (elective)

Edge-compute patterns ⚡ (elective)

Purpose: Push personalisation, experimentation and composition to the CDN edge while AEM stays fully cacheable.

Who this page is for

AudienceWhy it matters to you
Architects / senior engineersWhen cacheability and dynamism collide at scale

⚡ Elective — pull in when client-side patterns stop being enough

The core rule stands: cached HTML is identical for everyone; dynamic bits load client-side (integration placement). Edge compute (CDN workers/functions) is the next step when client-side costs too much: flicker-free personalisation, geo/segment routing, experiment bucketing at scale.

Patterns worth their complexity

PatternHowPHI example
Edge-side variant routingWorker inspects cookie/geo → fetches one of N cached variants (.seg-families.html selectors — each fully cached)Families vs singles hero on the plans landing page, no flicker
Edge HTML rewritingWorker streams cached page, substitutes a marked slot from a fast edge KV lookup"From $X/month" price freshness without page invalidation
Experiment bucketingWorker assigns/persists bucket, routes to variant URLsA/B at full cache speed, no client-side experiment flash
API composition at edgeWorker aggregates AEM JSON + pricing API for app clientsOne round-trip for the mobile plan screen
Auth token verificationWorker validates JWT before originMembers-area at edge speed

The costs (why this is an elective)

Adoption rule

Start with one pattern, one page family, full observability, and a documented fallback to the un-edged behaviour (worker off = plain cached page still correct). If a feature cannot degrade to that, it doesn't belong at the edge yet.

Quick navigation