Skip to main content
C
CIPHRX
ServicesCase StudiesBlogAbout
Start a project
All articles
Infrastructure··2 min read

Edge caching strategies that actually work at scale

How to cut origin load substantially with stale-while-revalidate, surrogate keys, and fine-grained cache invalidation.

C
CIPHRX
Engineering team

A common pattern we see on growing SaaS platforms: traffic climbs, database CPU saturates during peak hours, and API p99 latency drifts into seconds. The fix is rarely more origin capacity. It's smarter caching.

The cache hierarchy

Modern edge platforms give you multiple cache layers:

  1. Browser cache: Cache-Control headers
  2. CDN edge: PoP-level caching
  3. Regional cache: Shared across nearby users
  4. Origin cache: Redis, Memcached, or in-memory

Use all four, with different TTLs and invalidation strategies per resource.

Stale-while-revalidate

The most impactful single change is usually aggressive stale-while-revalidate (SWR):

Cache-Control: public, max-age=60, stale-while-revalidate=86400

This means:

  • First request fetches from origin, caches for 60 seconds
  • Subsequent requests serve from cache instantly
  • After 60 seconds, the next request still serves stale data but triggers a background revalidation
  • Origin has 24 hours to update before cache truly expires

For a product catalog, this kind of policy typically eliminates the vast majority of origin requests with no perceptible staleness.

Surrogate key invalidation

The hard part of caching is invalidation. Tag every cached response with surrogate keys:

  • product:12345
  • category:electronics
  • pricing:tier-pro

When a product updates, purge all responses tagged with product:12345. This invalidates the product page, category listings, search results, and recommendation carousels in a single operation.

Fine-grained API caching

GraphQL makes CDN caching tricky because every query is a POST to /graphql. Solve it by:

  1. Persisted queries: Every unique query gets a SHA256 hash and is served via GET
  2. Automatic query analysis: Extract entity types from the AST and attach surrogate keys
  3. Partial responses: Hot fields (prices, stock) are fetched separately from cold fields (descriptions, images)

What changes when this works

  • Origin request volume drops by an order of magnitude
  • API p99 falls to tens of milliseconds for cacheable reads
  • Database CPU stops being the bottleneck during traffic spikes
  • CDN cache hit ratio settles in the high 90s

When not to cache

Caching is not universal. Don't cache:

  • User-specific dashboards
  • Real-time financial data
  • Write operations
  • Admin panels

The key is understanding your data's consistency requirements and designing cache boundaries accordingly.

EdgeCachingVercelPerformanceCDN