Fastly Built the Fastest Cache Invalidation in the Industry. The Authority to Invalidate Still Lives in One Place.

Fastly's cache invalidation is genuinely fast. Their documentation states a global average purge time of 150 milliseconds, frequently faster. Their engineering blog describes a decade of work building a distributed multicast system so that when a purge request arrives, cache servers broadcast it to each other directly rather than routing everything through a central coordinator. The result is near-simultaneous invalidation across a global network at a speed that competitors have not matched.

That engineering achievement is real. It is also orthogonal to the structural question this article is about.

What Fastly solved, and what it didn't

Fastly's distributed purging solves a propagation problem: how do you get an invalidation signal to every cache node in the world as fast as possible? Their answer — intercept the signal at the edge and use bimodal multicast to distribute it peer-to-peer among cache servers — is clever and it works. Their own blog is candid about why: a centralized coordinator for purge distribution introduced a single point of failure and higher latency. The distributed approach eliminates that bottleneck.

But the propagation mechanism and the governance of invalidation are two different things. Fastly solved propagation. The authority to issue a purge request still flows from a single source: api.fastly.com.

Every purge in Fastly's system originates as an API call authenticated against Fastly's control plane. You hit the Fastly API, authenticated with a Fastly API token, and the purge propagates from there. The rate limit is 100,000 purges per customer per hour, enforced by Fastly's infrastructure. The service configuration that determines what can be purged and how lives in Fastly's control panel. The VCL or Compute code that governs caching behavior is deployed through Fastly's configuration system.

Fastly has not distributed authority over cache state. They have distributed the mechanism for propagating changes to cache state once that authority has been exercised. The edge nodes are fast executors of centrally-originated decisions. They are not governors of their own cache.

Why the distinction matters

The practical consequences of this distinction show up in three specific places.

Scoped cache policy. Every cache object on Fastly is governed by a single service configuration. Surrogate keys allow fine-grained purging of tagged groups of objects, which is genuinely useful. But the policy governing what those keys mean, who can purge them, and under what conditions is defined in the service configuration and enforced by Fastly's control plane. There is no mechanism for a region of the cache to hold its own policy about what it serves and when its content becomes stale. The cache has rules; it does not have governance.

Jurisdictional isolation. A content policy change that applies to one jurisdiction — a regulatory requirement to stop serving certain content in a specific region, for example — propagates through the same purge mechanism as any other change. The purge system does not have a concept of scoped authority. Fastly's infrastructure is globally coherent by design: a purge issued at the API level propagates globally. Regional behavior differences must be implemented through routing logic and VCL conditionals, not through governance that is structurally local to the region.

Structural adaptation. When traffic patterns shift significantly — a region grows large, a new geography emerges as important, a service needs to be restructured — those decisions happen through Fastly's configuration and deployment system. The cache nodes adapt to instructions. They do not self-govern adaptation. The edge executes; the center decides.

What changes when cache governance is local

The alternative is not a slower purge system. Speed of propagation and location of authority are independent properties. The structural alternative is a cache layer where each scope holds its own governance: the nodes responsible for a region of content hold the policy for that region, cache mutations are proposed through those nodes and validated by local consensus, and the invalidation decision is made by the nodes governing the affected scope rather than by an API call that originates upstream.

In this model, Fastly's propagation mechanism — fast, distributed, peer-to-peer broadcast — is not displaced. It is the right answer to the propagation problem. What changes is the origin of the signal. Instead of an API call authenticated against a central control plane, the invalidation originates from an anchor-governed mutation proposal: a change to a content scope proposed by the nodes governing it, validated through local quorum, and propagated through the network from there. The authority is local. The propagation is fast.

The practical consequences are concrete. A regulatory requirement that applies to a single region is handled by the anchors governing that region's scope, not by a global purge that the operator then has to scope manually through VCL. A cache scope that grows beyond its current structure can split into child scopes governed by the relevant anchors, without a service configuration change deployed through a central control panel. A content mutation that affects one semantic scope does not require touching the governance infrastructure of any other scope.

The remaining gap

Fastly is arguably the most serious CDN engineering organization in the industry. The decision to build distributed purge propagation rather than rely on a centralized coordinator was the right call. Their documentation even names the problem directly: centralized coordination introduces a single point of failure and higher latency.

The next step in that same direction — distributing not just the propagation mechanism but the authority that originates invalidation decisions — is what the adaptive index provides. Each scope in the namespace is anchor-governed. Mutations to cache state within a scope are validated by the nodes responsible for that scope. The control plane does not disappear. It distributes into the namespace itself.