Cache Bypass Patterns: When and How to Skip the CDN Cache

I’ll never forget the call I got at 2 a.m. during a holiday sale back in 2018. A retailer’s shopping cart was showing one customer’s items to another — because someone had set the CDN to cache everything, including the cart API. We fixed it in ten minutes by adding a cache bypass rule, but that bug cost them hours of sales and a lot of trust. If you’re working with a CDN for the first time, understanding when to skip the cache is just as important as knowing when to use it.

When You Must Bypass: The Content That Should Never Be Cached

Early in my career, I thought caching aggressively was always the right answer. More cache hits meant faster sites and happier clients, right? It took a few painful incidents to teach me that some content just isn’t meant to be stored at the edge. Anything personalized or unpredictable is a prime candidate for a full cache bypass. Think user account pages, shopping carts, checkout flows, and API responses that change per user. If you cache those, you aren’t speeding things up — you’re serving the wrong data to the wrong person.

There’s a simple test I run now before I cache anything. I ask, “Would I be okay if two different users got the exact same response from this URL?” If the answer is no, it needs to skip the CDN cache entirely. This is especially true for dynamic content CDN setups where the same endpoint, like /api/user/profile or /api/cart, returns completely different JSON depending on who’s logged in. Search results with user-specific filters, real-time inventory checks, and authenticated dashboards all fall into this bucket. You don’t want a cache skip to be an afterthought here; it should be your default.

Beginners often confuse this with just setting a short TTL. That’s not the same thing. A short TTL still stores the response and reuses it for a few seconds, which is enough to cause data leaks or stale pricing. A true cache bypass means the request goes straight to your origin every single time, with nothing stored at the edge. The HTTP Working Group Specifications define the headers that make this happen, and getting them right is the difference between “fast and correct” and “fast and broken.”

# Origin response headers that force a full cache bypass
# Use this for any personalized or dynamic endpoint

HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, private, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Vary: Cookie, Authorization
# no-store = don't store at all
# private = only browser can store, not shared CDN cache
# Vary tells caches that Cookie/Authorization changes the response

How to Tell the CDN to Get Out of the Way

So you’ve identified what shouldn’t be cached. How do you actually implement a cache bypass? You’ve got a few options, and I’ve used all of them depending on the stack. The cleanest way is with HTTP headers sent from your origin, like the Cache-Control: no-store example above. When the CDN sees no-cache or no-store or private, it knows not to cache. But you can’t always change origin code quickly, so most CDNs also let you create rules at the edge itself. That’s where you don’t have to touch your app at all.

In practice, I almost always set up bypass rules based on three things: cookies, URL patterns, and request headers. If a request has a session_id, auth_token, or cart cookie, I bypass. If the path is /api/*, /account/*, or /checkout/*, I bypass. I learned this the hard way after a client’s “add to cart” requests were cached because the URL didn’t change — the CDN saw POST /api/cart as cacheable. We fixed it by telling the edge to never cache any POST, PUT, or DELETE request, and to skip the cache when an Authorization header is present. For more complex setups, you’ll want to understand how Cache Coherence Protocols at the CDN Edge: Keeping Distributed Caches in Sync interact with your bypass logic so you don’t create coherence issues elsewhere.

// Cloudflare Worker / Fastly VCL-style edge logic for cache bypass
// This runs at the edge before checking the cache

function shouldBypassCache(request) {
  const url = new URL(request.url);
  
  // 1. Bypass for dynamic content paths
  if (url.pathname.startsWith('/api/') || 
      url.pathname.startsWith('/account/') ||
      url.pathname.startsWith('/checkout/')) {
    return true;
  }
  
  // 2. Bypass if user is authenticated
  const cookie = request.headers.get('Cookie') || '';
  if (cookie.includes('session_id=') || cookie.includes('auth_token=')) {
    return true;
  }
  
  // 3. Bypass for non-GET methods - never cache writes
  if (request.method !== 'GET' && request.method !== 'HEAD') {
    return true;
  }
  
  return false;
}

What Skipping the Cache Really Costs You

There’s no sugar-coating it: every time you trigger a cache bypass, you’re paying for it in latency and origin load. I’ve had junior engineers worry that bypassing too much will “defeat the purpose” of the CDN, and they’re not wrong to worry. But the alternative — serving stale or private data — is always worse. The trick isn’t to avoid bypasses, it’s to be surgical about them. You want to bypass exactly what needs bypassing and cache everything else aggressively. Guidance from web.dev Articles on caching strategies backs this up: cache static assets forever, revalidate HTML carefully, and never cache personalized responses.

Let me give you some real numbers from a mid-size e-commerce site we migrated last year. Before we tuned their bypass rules, they were caching everything with a 60-second TTL and seeing weird bugs. After we implemented proper path and cookie-based bypasses, their overall cache hit ratio dropped a bit, but the user-facing errors vanished. The trade-off was absolutely worth it. If you’re trying to predict what *should* be cached instead of just blocking what shouldn’t, projects like Machine Learning for Cache Warming: Predictive Prefetching That Actually Works are interesting, but for beginners, a clear bypass list is more reliable than any prediction.

Here’s what the performance profile typically looks like when you compare the options. These are averages we measured over a 7-day period with about 5 million requests per day on a standard Fastly/Cloudflare-style edge network:

Bypassing in Practice: VCL, Workers, and Edge Config That Actually Ships

Knowing what to bypass is the easy part. Making it bulletproof at the edge without accidentally taking your origin down is where teams get burned. You’ve got three places to enforce a bypass: origin headers, CDN configuration, and edge compute. In production, you’ll want at least two of them agreeing — defense in depth beats a single clever rule every time.

Origin headers are your source of truth, but they’re slow to change. If your app sends Cache-Control: private, no-store for authenticated responses, a well-behaved CDN will respect it. The problem is CDNs don’t all interpret headers the same way, and header logic won’t help you with request-based bypasses like “skip cache if this cookie exists.” That’s where edge logic comes in. At Fastly/Varnish you’d use VCL, at Cloudflare/Akamai/Fastly Compute you’d use a Worker. I prefer to keep the logic explicit and auditable — no regex magic you can’t grep in six months.

Here’s the pattern we run for most e-commerce and SaaS apps — selective pass-through based on auth, path, and cookie, with a safety net for preview/bypass headers. It keeps your cache hit ratio above 92% for anonymous traffic while guaranteeing logged-in users and cart/checkout flows never see stale data. Test it with curl -I -H "Cookie: session=abc123" and watch for X-Cache: MISS + Cache-Control: private on the way back. If you see HIT where you expected MISS, your rule isn’t firing early enough in vcl_recv or fetch().

// Cloudflare Worker / Fastly Compute@Edge - selective cache bypass
export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
    const hasSession = request.headers.get('Cookie')?.includes('session=');
    const isSensitivePath = /^\/(api\/(cart|checkout|account)|admin|preview)/.test(url.pathname);
    const hasAuth = request.headers.has('Authorization');

    // 1. Hard bypass: never cache these
    if (hasSession || hasAuth || isSensitivePath) {
      // Force origin, don't store response
      return fetch(request, {
        cf: {
          cacheEverything: false,
          cacheTtl: 0,
          cacheTtlByStatus: { "200-299": 0, "300-599": 0 }
        }
      });
    }

    // 2. Soft bypass via header (for editorial previews)
    if (request.headers.get('X-Cache-Bypass') === '1') {
      const originRes = await fetch(request, { cf: { cacheTtl: 0 } });
      const res = new Response(originRes.body, originRes);
      res.headers.set('Cache-Control', 'no-store, private');
      return res;
    }

    // 3. Default: respect origin cache headers + edge TTL
    return fetch(request, { cf: { cacheTtl: 300 } });
  }
}

// Equivalent VCL snippet for Varnish/Fastly:
// sub vcl_recv {
//   if (req.http.Cookie ~ "session=" || req.http.Authorization || req.url ~ "^/(api/cart|checkout|account)") {
//     return(pass);
//   }
// }

Advanced Patterns: Tiered Bypass, Collapsed Forwarding, and Debugging When It All Goes Sideways

The most expensive bug I see isn’t bypassing too little — it’s bypassing too much with a single sloppy rule like if (req.http.Cookie) { return(pass); }. That one line will tank your hit ratio from 96% to 18% overnight because every bot with a _ga cookie now punches through to origin. We’ve measured 12k RPS of cacheable anonymous traffic suddenly hitting origin because of that regex. Scope it tightly: check for session= or auth_token=, not just Cookie:.*. And remember, consistent hashing is what keeps your cache nodes from duplicating content — if you bypass inconsistently across POPs, you’ll amplify origin load unevenly. If you haven’t mapped how your traffic shards, read Consistent Hashing for CDN Cache Distribution: A Practical Implementation Guide before you tune bypass rules.

Don't confuse bypass with invalidation. If you're bypassing just because content changes frequently, you're leaving performance on the table. A better trade-off is often stale-while-revalidate plus targeted purging. For example, serve product JSON with Cache-Control: max-age=60, stale-while-revalidate=600 and purge by tag on update, rather than bypassing the entire /api/products/* path. This cuts origin requests by 80-90% during a flash sale while keeping data < 60s fresh. Check out Cache Tag Design Patterns: Organizing Content for Granular Invalidation and Surrogate Keys for Targeted Cache Purging: Beyond URL-Based Invalidation for a cleaner alternative to “bypass everything dynamic.” And always enable collapsed forwarding / request coalescing — when you do have to bypass, you don’t want 400 edge nodes collapsing on origin simultaneously for the same uncacheable resource.

When bypass misbehaves, triage with headers, not hunches. First, add debug headers at the edge: X-Cache-Decision: bypass-cookie or X-Bypass-Reason: auth-header so you can see why it bypassed. Second, log Age, X-Cache, CDN-Cache-Control, and Surrogate-Control on every response — if Age: 0 but X-Cache: HIT, you’re looking at a shield POP hit masking an edge miss. Third, watch origin 95th percentile during rollouts. A correct selective bypass should add maybe 15-40ms for the 5-10% of traffic that bypasses; if your p95 jumps 200ms+ for cacheable traffic, you’ve got a rule-ordering issue. We’ll often shadow-deploy a bypass rule in “log-only” mode for 24 hours before enforcing it — you’ll catch the cookie explosion before it becomes an incident.

Frequently Asked Questions