Content Delivery & CDN Architecture

Agility delivers published content and media through Fastly, a globally distributed CDN: the content APIs (Content Fetch / GraphQL) and the asset CDN are fronted by Fastly's edge network so that requests are served from the location nearest the end user, minimizing latency. This is Agility's platform delivery layer, and it is distinct from a customer's own front-end CDN — the CDN a customer puts in front of their website or application (e.g. via their hosting/Vercel/Netlify/Cloudflare setup). In a typical production architecture there are effectively two CDN layers: Agility's platform CDN serving content/assets to the application, and the customer's front-end CDN serving rendered pages to browsers. Understanding the split clarifies who controls caching, invalidation, and edge behaviour at each layer.

Agility's platform delivery layer

Agility's APIs and assets are served from a global CDN:

Content APIs (Fetch / GraphQL): responses are CDN-backed and cacheable on Fastly; a response served from the Agility CDN cache does not count against API rate limits.
Asset CDN (cdn.aglty.io): images and files are stored on Microsoft Azure and delivered via Fastly, with edge caching, cache-control rules, and on-the-fly image optimization (resize/format) available via query-string transformations.
Edge distribution: content and assets are cached at Fastly edge locations (POPs) close to users; the nearest edge server responds, and only cache misses reach the Azure origin.
Instant cache invalidation: when content is published, the relevant cached content is invalidated at the edge instantly, so updates propagate immediately rather than waiting for a TTL to expire.

A customer's own front-end CDN

Production sites built on Agility are usually statically generated or server-rendered and deployed behind the customer's own hosting and CDN (for example, the CDN built into Vercel, Netlify, Azure Front Door, Cloudflare, etc.). This front-end CDN:

Caches and serves the rendered HTML/pages and front-end assets to browsers.
Is owned and configured by the customer/partner — its cache TTLs, invalidation, WAF, geo rules, and failover are the customer's responsibility.
Is independent of Agility's platform CDN: the front end fetches content from Agility's APIs (often at build time or via revalidation), then serves end users from its own edge.

The two-layer model

	Agility platform CDN	Customer front-end CDN
Serves	Content API responses + media assets	Rendered pages + front-end assets
Consumer	The customer's application / build	End-user browsers
Owned by	Agility	Customer / implementation partner
Cache invalidation	Instant — Agility invalidates cached content at the edge on publish; also exposes webhooks for downstream revalidation	Configured by the customer (cache tags, on-demand revalidation, TTLs)
Origin	Agility's content platform on Azure	The customer's app/host, which in turn calls Agility's APIs

This separation is also why end-user availability is so resilient: even if Agility's origin/API layer has a brief event, a statically generated site behind the customer's CDN keeps serving already-rendered pages (see SLA & Uptime and Disaster Recovery & Business Continuity).

Shared responsibilities

Area	Agility	Implementation partner / customer
Platform content/asset CDN	✅ Operates global edge delivery for APIs + assets	—
Image optimization / transformation	✅ Query-string transforms on asset CDN	✅ Requests appropriate sizes/formats
Front-end CDN	—	✅ Selects, configures, and operates its own CDN (TTLs, invalidation, WAF, geo rules)
Cache invalidation end-to-end	✅ Provides webhooks/revalidation triggers	✅ Wires revalidation into the front end and its CDN
Delivery-residency constraints	✅ Operates platform edge	✅ Enforces any geo-restriction at the front-end CDN if required (see Data Residency)