A reader clicks a link to a breaking news story. The page loads instantly. Behind the scenes, the rendering service that built that page might be recovering from an error. The reader never notices.
Arc XP’s CDN is built for exactly this. When things go wrong at the origin, the network keeps serving content.
What is CDN? (in 30 secs)
A Content Delivery Network caches copies of your website at servers distributed around the world. Instead of every request traveling back to the origin server, most get answered by a nearby cache. Each cache location is called a PoP (Point of Presence), and within each PoP there are multiple nodes — individual servers handling requests. Content has a cache life, a TTL (Time to Live), that determines how long a cached copy is considered valid before it goes stale and needs to be refreshed from the origin.
Here’s how it works, from the edge all the way back to rendering.
How Arc XP distributes content globally
Arc XP’s CDN uses DNS to route users to a balanced set of PoPs across more than 4,200 edge instances in 130+ countries. The routing factors in geographic location, latency, and regional load. Users receive multiple IP addresses for connection, which means a single reader may interact with several PoPs during a session.
Within each PoP, requests are balanced across nodes. Nodes are invisible to the end user. Only the public PoP IP address is exposed. Each node follows the same logic when handling a request:
- Valid object locally? Serve it directly.
- Stale object (TTL expired or purged)? Check within the PoP for a newer version and use it.
- No object at all (new node)? Also check within the PoP for a valid cached copy.
This is standard behavior for major CDN providers. For a visual walkthrough of this request flow, see Arc XP’s CDN Caching on the developer documentation.
How content stays fresh
When a node has a stale object or no object at all, it serves the best available stale content to the reader while making a refresh request forward to rendering. The response from rendering gets stored on both the requesting node and any node within the PoP that had the “newer” stale object. This spreads fresh content across more nodes with each request, improving performance for subsequent readers. But it doesn’t guarantee every node in the PoP gets the update — nodes that didn’t receive a request can still hold older stale content.
The tiered hierarchy
Behind the edge PoPs, Arc XP uses a multi-layer hierarchy. Each refresh request from the edge may pass through several layers, and every layer follows the same caching logic that the edge does. Content can exist in both current and stale forms across these layers, depending on request volume to specific nodes within each PoP.
Without intervention, different regions of the world would get responses from different renders. A reader in Tokyo might see one version of an article while a reader in London sees another. Arc XP’s architecture prevents that.
The central cache
The last layer before rendering is a central cache (referred to as the Cloud Wrapper layer in Arc XP’s CDN documentation). It has the same valid and stale states as every other layer, but it’s designed to handle high request rates and ensure the same object is used for all parallel global requests.
It’s the consistency anchor. When edge nodes across the world request a refresh at roughly the same time, the central cache makes sure they all get the same rendered response.
The central cache still operates like the other layers in one respect: if a node within it hasn’t seen a request, it can still hold stale content of varying ages. That content would be subject to refresh if requested, but its role during error conditions matters too.
What happens when rendering fails
When rendering returns an error, the central cache treats it as a revalidation success (304). The original cached object gets resurrected with its original TTL. There’s no new rendered response to replace it, so the central cache serves whatever stale content exists on the node that received the request.
Responses from the central cache can vary based on the local state of the specific node that handled the request. Upstream, edge nodes cache the revalidated object as they would any normal origin response and serve it for the revalidated TTL.
Readers keep getting content. A rendering failure doesn’t become a reader-facing outage. The CDN caching FAQ on the developer portal covers common scenarios around this behavior.
The special case: 401, 403, and 429 errors
One deviation from this pattern exists for 401 (Unauthorized), 403 (Forbidden), and 429 (Too Many Requests) responses from rendering. The HTTP spec marks these as non-cacheable, so the central cache can’t simply revalidate the stale object. Instead, it converts the response to a 503 (Service Unavailable).
The revalidation of the original object then happens at the downstream nodes, at the edge PoPs within the tiered hierarchy. Stale content for these error codes depends on local cache availability across multiple PoPs. This makes the durability less predictable than standard failure codes, but content still gets served where local caches have it.
What durable actually means
The goal is straightforward: protecting your reader experience at all costs. Serving content when downstream systems fail, even when something breaks at the origin. Either way, the reader gets a fast, working website.
This CDN durability is one part of a larger caching architecture. Arc XP also caches at the PageBuilder layer, which protects downstream APIs and gives developers control over content freshness per content source. Together, these layers handle billions of requests while keeping origin load predictable.
For the full picture, see Caching at Arc XP and the how Arc XP scales to billions blog post.
