Fastly CDN Setup: VCL, Instant Purge, Compute@Edge

Fastly CDN: Where the Cache Breaks and Why Requests Go to Origin

As a rule, Fastly CDN response time is determined not by server capacity but by the share of requests that end in a cache hit. While this share is high, the page is served from the nearest node and never reaches your application. As soon as it drops, every cache miss turns into a full request to origin.

The causes of misses are almost always the same. The cache key is assembled in too much detail: it includes ad tags, service cookies, extra headers, and sorting parameters, and each unique combination creates a separate version of the object.

A short TTL finishes the picture — the object expires before it can be reused, and the node goes to origin for the very same thing.

Then accumulation kicks in. Origin is designed for average traffic, not for the share of misses during a sale or publication: response time grows, some requests time out, and retries add load. Thus infrastructure that handled an ordinary day stops responding during the peak hour.

Cache invalidation is a separate trap. If you purge everything entirely, the cache becomes empty for a time and all traffic goes to origin at once. If you wait for the TTL to expire, the user sees stale data after a catalog or price update. The workable option is targeted purging by specific objects and content classes.

We cover how this is addressed: by designing the cache key, using different TTLs for static and dynamic content, targeted invalidation, and protecting origin from a repeated set of requests.

What Moving the Cache to Edge Nodes Delivers: The Effect in Numbers

An edge cache places the response next to the user: the nearest node serves a ready copy in tens of milliseconds instead of hundreds while the request travels to the origin.

Response time stops depending on geography, and origin stops being the point where every request hits a wall.

The key metric is the hit ratio: how many requests are served by cache without contacting the origin.

It grows not by "turning settings to maximum" but by cache keys and content markup: we normalize the key, discarding ad tags, set rules by paths and file types, and separate TTLs for static and dynamic content. A response that cannot be cached in full, we assemble at the edge from cached fragments.

Load reduction is calculated directly: how much traffic did not reach origin. On typical content, this is the majority of requests — origin stops being a bottleneck.

Resilience to peaks comes the same way: a spike from a sale or publication is absorbed at the nodes, and origin sees a steady flow instead of a tenfold one.

Along with this, a class of failures goes away — timeouts and queues at origin, cascading errors under load, "the site is down" at the most expensive moment.

A large TTL stops being a risk here: targeted purging removes stale content from the nodes in seconds, an edit goes live almost immediately, and the hot cache is not rebuilt entirely.

On Fastly, cache and routing logic is described in VCL and can execute on the nodes themselves — header normalization, redirects, and access checks are handled before origin.

Origin is offloaded not by "proxying" but by the fact that some of the work simply does not reach it.

Connection Formats and Operating Modes of Fastly CDN

The choice of delivery scheme for Fastly CDN determines not only the cache hit ratio but also which caching headers you will have to support in the application.

At the start, you realistically choose between three combinations — they differ in the failure point and the amount of logic you move to the edge.

Three Working Combinations

Caching modes differ in the cost of an error: static content can be cached for a long time without risk, dynamic content only with instant purge by key.

The hybrid gives the best return but requires VCL rules and thoughtful invalidation: without targeted purge, a short response TTL turns into a constant stream of requests to origin. Below we cover how this is configured and load-tested.

How Implementation Proceeds: Stages of Engineering Work

We structure Fastly implementation so that the caching scheme appears before the first release, rather than being assembled after incidents. The order of stages is the same for a new project and for migrating an already working delivery setup.

1. Traffic audit. We collect statistics by route: share of dynamic content, distribution by region, response size, share of requests with authorization and personal data. The output is a flow map and a list of what must never be cached under any circumstances.
2. Caching scheme. We define the cache key, TTL for each content class, rules for normalizing query parameters, and separation by language and device type. Separately, we record what is purged via Instant Purge and what survives a release.
3. Processing rules. We write VCL: path rewriting, redirects, header and error handling, different TTLs for static content and markup. Logic that is too cramped in VCL we move to Compute@Edge.
4. Load testing. We run traffic close to peak: we look at the cache hit ratio, response time on a cold and warm cache, and behavior when origin is unavailable. We separately test purge and warm-up scenarios so that a release does not overwhelm origin.
5. Handover to operations. Configurations and rules go into the repository, changes go through review and are rolled out across environments. We provide documentation, a metrics map, and rollback procedures — the scheme can be changed without reconstructing the work history from scratch.

Configurations, Diagrams, and Policies That Stay with You

We consider the project complete not when traffic starts flowing through the edge network, but when your team can independently change cache behavior and understand the consequences.

That is why, along with access, we hand over a set of artifacts that allow work to continue without us.

• Cache configuration — VCL files with rules by paths and content types, object TTLs, purge by tags, and correct origin error handling.
• Flow map — request flow diagram: routing, path rewriting, points where edge logic connects, and where cache hits and misses occur.
• Access policies — restrictions by addresses and tokens, signed links, environment separation, and a role matrix: who can change what and in which environment.
• Edge logic — function source code with descriptions of inputs, outputs, external dependencies, and environment variables.
• Documentation — what is where, why each rules block is needed, how to bring up the configuration from scratch, and how to test it locally.
• Change policy — the procedure for edits: branch, review, deployment to a test environment, testing on a portion of traffic, and rollback to the previous version in minutes.
• Observability — a set of metrics (hit ratio, errors, response time), alert thresholds, and a list of on-call actions for degradation.

We agree on the change policy with your team before handover so that it matches your review process rather than living separately from it. The output is not a one-time result but a managed Fastly configuration with clear entry points for new engineers.

Case Study: Offloading Origin and Metrics Before and After Implementation

The client is a retail online service with sharp peaks: sale launches, mass mailings, social media campaigns.

The perimeter on Fastly was used almost as a transparent proxy: default settings, only static content was cached, and the catalog and product pages went to origin for data every time.

At peak, this turned into an avalanche of identical requests to application servers: the database hit connection limits, and autoscaling lagged behind load growth.

During traffic analysis, we found three bottlenecks. The cache key did not account for response variants — language, currency, authorization status — so the hit ratio stayed at 35–40%, and some visitors risked getting the wrong version of the page.

Purging was done in full on a schedule, and after each deployment the morning peak went through a "cold" cache.

Plus, there was no request coalescing: while the first request was assembling the page, hundreds of parallel ones waited for it and held connections to the database.

We rewrote the VCL rules: the cache key was assembled from attributes relevant to the response, static content and catalog pages were separated by TTL, and instead of full purging we moved to targeted invalidation by tags when a product page was updated.

We added serving a stale copy while a fresh one is assembled in the background, and collapsing identical requests into a single trip to origin. The logic for address normalization and serving page variants was moved to the edge so that the request would not reach the application.

• share of responses from cache: 38% → 92%
• requests to origin in the peak minute: 6x fewer
• response time at the 95th percentile: three times shorter
• 5xx errors at peak: 3.8% → 0.1%
• the application server fleet was not increased, even though the peak grew threefold

Rollback is reverting to the previous set of rules, which takes minutes. Origin stopped being a bottleneck, and the edge now handles peak load without growing the application infrastructure.

How Instant Cache Invalidation Differs from a Full Purge

Instant invalidation removes specific objects from the cache — by URL or by a tag that we assign to a group of objects when serving them. A full purge resets the node's cache entirely, and until warm-up every request goes to the origin server.

The difference is in the cost of an error: targeted purge leaves the cache warm, while a full one zeroes it and opens a stream of requests to the backend.

Cache tags are the main tool: one object can carry several tags, so updating a product group is done in one operation and does not affect the rest of the site.

In Fastly CDN, the propagation time for such invalidation across the network is a fraction of a second, so content versions switch without a waiting window.

Full purge remains an emergency mode: it is needed when tag assignment rules turn out to be incorrect or when stale data must be reliably excluded. The risk here is that until warm-up, origin serves some requests, and under peak load this is noticeable. Therefore, by default we build the scheme on tags and keep full purge as a controlled exception.

Technical Concerns: Configuration, Limits, Rolling Back Changes

Before infrastructure acceptance, the same questions come up — about cache limits, rolling back rules, and failure behavior. Below are short answers: this shows exactly what we fix in the configuration and in the on-call policy.

What cache limits do we set, and how is content updated?

We set TTL and update rules by content type: static content lives long, pages for minutes. While the object is being rebuilt at origin, the visitor receives the previous version instead of waiting. We purge in a targeted way by key or tag — editing one page does not reset the entire cache.

Are requests from authorized users cached?

By default, no — otherwise one visitor would receive another's data. If caching is needed, we design the key so that responses for different accounts do not overlap. We verify this with tests before rolling out to production traffic.

What happens if a node or region fails?

Traffic goes to the nearest live nodes, and if they are unavailable, along a backup route to origin. Timeouts and failover order are defined in advance, so degradation is predictable: the site responds more slowly but does not return an error to everyone.

Let's Discuss Your Task: What to Prepare for the Conversation

Estimating a content delivery task depends not on the volume of configuration but on how complete the inputs are.

The more precisely the delivery scheme, traffic profile, and freshness requirements are described, the faster we will return with a work plan and clear areas of responsibility — without two-week clarification cycles.

• Delivery scheme. How many content origins there are and where they are located, whether there are intermediate caching layers, and who serves static content today. If some routes already go through a CDN, attach the current caching rules.
• Traffic profile. Peak requests per second, static-to-dynamic ratio, share of unique URLs, audience geography, and how much load search engine bots and monitoring generate.
• Freshness requirements. How many seconds it is acceptable to serve a stale response for each content type, and which sections require instant cache purge after publication. This determines where we set long TTLs and where we use event-based purge.
• Request processing rules. What is needed at the delivery logic level: redirects, address rewriting, normalization, link signing, and region-based access restrictions. Separately — which headers the origins currently return.
• Integration points. Build and deployment pipeline, content publishing system, metrics and log collection, DNS and certificates, and external security services.
• Failure behavior. Expectations for failover between origins, what to show the user when they are unavailable, and which scenarios are considered degradation versus an outage.
• Access and policy. Who owns DNS and certificates, which roles engineers need, and whether there are restrictions on change windows and approval of production edits.

Send what you already have: a diagram, a log export for a day or two, and a list of critical sections. Describe the task in this form — we will return with an estimate, a work plan, and an implementation sequence.