CDN vs Local Caching: 10 Questions [Solved]

What does CDN caching actually cache?

CDN caching stores complete HTTP responses at edge servers—usually static files with predictable content. When a request arrives, the CDN checks if it already has a valid cached copy. If yes, it returns that copy without contacting your origin. If no, it fetches from origin, stores the response, then serves it.

The CDN decides what to cache based on HTTP headers you send: Cache-Control, Expires, and sometimes custom headers like Surrogate-Control. A response with Cache-Control: public, max-age=31536000 tells the CDN to store it for a year. A response with Cache-Control: private or no-cache tells the CDN not to cache it at all.

In support tickets I handled, the most common mistake was letting the CDN cache HTML pages that included logged-in user names or CSRF tokens. Always mark dynamic or personalized responses as private.

What does local server caching store?

Local caching on your origin server stores intermediate computation results—database query outputs, rendered HTML fragments, serialized objects, or expensive API calls. Technologies like Redis, Memcached, or even file-based caches sit between your application and the database.

When your app needs a blog post, it checks the local cache first. Cache hit means the post HTML is already in memory; return it instantly. Cache miss means query the database, render the template, store the result in cache with a TTL, then return it. The next hundred requests skip the database entirely.

• Redis or Memcached for key-value storage with millisecond lookup times
• Application-level caching in frameworks like Django, Rails, or WordPress with object cache plugins
• Opcode caches like OPcache that store compiled PHP bytecode to skip parsing on every request

How do I decide which content belongs in which cache?

Start with content type and update frequency. Static files that never change per user go in the CDN: images, CSS, JavaScript libraries, fonts, PDFs. These benefit most from edge delivery because they're large, requested often, and identical for everyone.

Dynamic content that varies by user or changes frequently stays in local cache: session data, shopping cart contents, personalized recommendations, real-time inventory counts. Putting these in the CDN either leaks private data or causes stale responses because you can't purge fast enough.

Gray area items like blog posts or product pages can use both. Cache the rendered HTML locally for ten minutes to handle traffic spikes, and let the CDN cache it for an hour with a public header. When you publish an update, purge both layers.

Why does cache invalidation matter more with CDN?

Local cache invalidation is instant—you clear Redis or restart the app server and the stale data is gone. CDN invalidation requires API calls to each edge location, and propagation can take seconds to minutes depending on the provider.

The delay creates a window where some users see old content and others see new content, which confuses QA teams and creates duplicate support tickets. Worse, if your purge request fails or you forget an edge location, stale copies persist until the TTL expires.

Three patterns reduce this pain. One, use versioned URLs like style.v2.css so each deploy creates a new cache key. Two, set shorter TTLs on content that changes often, accepting the cache-miss cost. Three, configure your CDN to revalidate with If-Modified-Since so it can confirm freshness without a full refetch.

What is the double-caching bug?

Double-caching happens when both your local cache and the CDN store the same response with independent TTLs and no coordination. You update the local cache, but the CDN still serves the old version for another hour. Or you purge the CDN, but the origin cache still returns stale data, which the CDN immediately re-caches.

I've seen this break checkout pages where the local cache stored a cart total, the CDN cached the entire checkout HTML, and when inventory changed the local cache updated but users kept seeing the old price until the CDN TTL expired.

• Fix it by using different cache keys: version strings in asset URLs for CDN, database record timestamps for local cache
• Chain purges: when local cache invalidates, trigger a CDN purge via API in the same transaction
• Never cache the same response with overlapping lifetimes unless you control both expiration triggers

So what if my CDN is caching private data?

Check the response headers your app sends. Run curl -I https://yoursite.com/account and look for Cache-Control. If you see public or no explicit cache directive, the CDN might store it.

Add Cache-Control: private, no-store to any response containing user-specific information—account pages, order history, API endpoints that return personal data. The private directive tells the CDN to skip caching; the no-store directive tells browsers not to cache either.

For APIs, also check the Vary header. If responses differ based on cookies or authorization tokens, include Vary: Cookie or Vary: Authorization so the CDN creates separate cache entries per user. Better yet, don't cache authenticated endpoints at the edge at all—serve them from origin with local caching only.

How do I test if caching is working?

Use curl to inspect headers and timing. First request shows a cache miss:

curl -I https://yoursite.com/image.jpg | grep -E 'X-Cache|Age|Cache-Control'

You'll see X-Cache: MISS or Age: 0. Second request should show X-Cache: HIT and Age: 5 (seconds since cached). If Age keeps resetting to zero, the CDN isn't caching.

For local cache, add debug logging to your app that prints whether each request hit or missed the cache layer. In production, monitor cache hit ratio—above 80 percent means your cache keys and TTLs are well-tuned. Below 50 percent means too many unique keys or TTLs set too short.

Quick reference table

Here's a comparison table for common scenarios:

• Static assets (images, JS, CSS): CDN with 1-year TTL, versioned URLs to bust cache on deploy
• Blog posts and marketing pages: CDN with 1-hour TTL + local cache with 10-minute TTL, purge both on publish
• Product catalog pages: CDN with 5-minute TTL + local cache with 1-minute TTL for inventory updates, Vary: Cookie if prices differ per user
• User dashboards and account pages: No CDN caching (Cache-Control: private), local cache with session-specific keys
• API responses for public data: CDN with short TTL (1-5 minutes), include ETag for revalidation
• API responses for authenticated users: No CDN caching, local cache keyed by user ID with 30-second TTL
• Database query results: Local cache only with TTL matching update frequency (1-60 minutes depending on table)
• Session data and shopping carts: Local cache only with TTL matching session timeout, never send to CDN

Common pitfalls and how to avoid them

Forgetting to set Vary headers when content differs by user agent or geography causes mobile users to see desktop assets or vice versa. Add Vary: User-Agent if you serve different HTML to mobile, or let the CDN normalize it.

Caching error pages with long TTLs makes your site look broken even after you fix the issue. A 500 error cached for an hour means users see failures long after your database comes back online. Set Cache-Control: no-cache, no-store on all 4xx and 5xx responses.

Not monitoring cache hit ratios means you won't notice when a code change breaks caching. I've seen a single extra query parameter added to URLs drop hit rates from 90 percent to 10 percent because each URL became unique. Track metrics and alert on sudden drops.

When to skip CDN caching entirely

If your traffic is regional and your origin server sits in the same data center as most users, CDN edge caching adds latency instead of removing it. A server in Frankfurt serving mostly German traffic doesn't need edge locations in Tokyo and São Paulo.

Highly dynamic sites where every response is personalized also see little benefit from edge caching. A social feed that differs for each user can't be cached at the edge—local caching of the database queries and rendered components gives better results.

Content behind authentication should stay on origin unless you use a CDN that supports signed URLs or token-based access control. Putting a login-walled document on a public CDN edge without access checks is a data leak waiting to happen.