What is Granular Caching? | Advanced Cache Key Segmentation

Granular Caching uses Advanced Cache Keys to store different versions of the same content based on specific HTTP request information — enabling personalized caching without session contamination.

What is Granular Caching?

Granular Caching is the ability to define what should be cached based on specific HTTP request information. Unlike “all or nothing” caching, Granular Caching uses Advanced Cache Keys to segment stored content.

This technique answers a specific question: “What exactly should I cache — and with what segmentation rule?”

While Micro Caching defines how long to cache, and Tiered Caching defines how many layers to distribute cache across, Granular Caching defines what to cache and with what key.

How Granular Caching works

When a request arrives at a point of presence in the distributed infrastructure, the system builds a cache key — a unique identifier that determines whether a cached response exists for that specific request.

In basic caching, the cache key is typically just the URL. In Granular Caching, the cache key includes additional segmentation criteria:

Basic Cache Key: /api/product/123
Granular Cache Key: /api/product/123 + header:Device-Type + cookie:session_id

This means different users or devices can receive different cached versions of the same URL — without mixing data between sessions.

Advanced Cache Keys: segmentation options

Segmentation by header

Store different versions of a response based on HTTP headers like Device-Type, Accept-Language, or User-Segment.

Use cases:

• Serve different content for mobile vs. desktop users
• Cache API responses by content type (Accept: application/json vs. Accept: text/html)
• Segment by user preferences (Accept-Language: en-US vs. Accept-Language: pt-BR)

Example:

URL: /api/product/123
Header: Device-Type = mobile
Cache Key: /api/product/123:Device-Type:mobile

Segmentation by cookie

Cache personalized page fragments without mixing data from different sessions.

Use cases:

• Cart summary fragments cached per session
• User-specific recommendations
• A/B test variants by user group

Example:

URL: /api/cart/summary
Cookie: session_id = abc123
Cache Key: /api/cart/summary:session_id:abc123

Segmentation by query string

Treat search parameters, filters, or campaign parameters as cache differentiation criteria.

Use cases:

• Search results with different filters
• Product listings sorted by price, name, or relevance
• Campaign tracking parameters (?utm_source=email)

Example:

URL: /api/products?category=shoes&sort=price
Cache Key: /api/products:category:shoes:sort:price

Granular Caching vs. other caching strategies

All four strategies are complementary — not mutually exclusive.

Combining Granular Caching with Micro Caching

Granular Caching and Micro Caching work together to provide both segmentation and freshness:

1. Granular Caching defines the key — which combination of headers, cookies, or query strings uniquely identifies this data
2. Micro Caching defines the time window — how many seconds data can be reused
3. Selective bypass ensures the boundary — critical operations bypass cache completely

Example flow:

Shipping request
      ↓
[Granular Cache Key: ZIP prefix + Device-Type]
      ↓
[Micro Cache TTL: 5 seconds]
      ↓
Cache HIT → immediate response
Cache MISS → origin → populates cache → response

When to use Granular Caching

Use Granular Caching when:

• The same URL needs different responses for different users or devices
• You’re caching personalized content without session contamination
• APIs return different data based on headers or query parameters
• You need to implement A/B testing with cached variants
• User-specific fragments can be safely cached with proper segmentation

Avoid Granular Caching when:

• Content is truly static and identical for all users
• Segmentation would create too many cache variants (cache fragmentation)
• The overhead of managing multiple cache keys outweighs the benefit
• Data is highly sensitive and should never be cached

Best practices for Granular Caching

1. Keep cache keys focused

Only include segmentation criteria that actually affect the response. Adding unnecessary criteria creates cache fragmentation and reduces hit ratio.

2. Use consistent key ordering

Define a consistent order for cache key components to ensure the same request always generates the same key.

3. Implement proper invalidation

When user state changes (cart update, preference change), invalidate only the affected cache keys — not the entire application.

4. Monitor cache hit ratio by variant

Track hit ratios for each cache variant to identify over-segmentation or under-utilization.

5. Combine with selective bypass

Ensure operations that shouldn’t be cached (payment authorization, order finalization) explicitly bypass cache regardless of segmentation rules.

Real example: personalized product recommendations

An e-commerce platform uses Granular Caching to cache personalized product recommendations:

Cache key configuration:

URL: /api/recommendations
Headers: User-Segment, Accept-Language
Cookies: user_preferences
TTL: 30 seconds

Result:

• Different user segments receive different cached recommendations
• Language variants are cached separately
• User preference changes trigger targeted invalidation
• Origin load is reduced while maintaining personalization

FAQ

What is Granular Caching?

It’s a caching technique that uses Advanced Cache Keys to store different versions of the same content based on specific HTTP request information like headers, cookies, or query strings.

How is Granular Caching different from basic caching?

Basic caching typically uses only the URL as the cache key. Granular Caching adds segmentation criteria to create multiple cached variants of the same URL.

When should I use Granular Caching?

Use it when the same URL needs different responses for different users, devices, or contexts — such as personalized content, device-specific layouts, or A/B testing.

What are Advanced Cache Keys?

They’re cache identifiers that include additional request information beyond the URL — such as headers, cookies, or query string parameters — to create segmented cache variants.

Can Granular Caching cause cache fragmentation?

Yes, if you include too many segmentation criteria. Only include criteria that actually affect the response content.

How does Granular Caching work with Micro Caching?

Granular Caching defines what to cache and with what key; Micro Caching defines how long to cache. They’re complementary strategies that work together.

Conclusion

Granular Caching solves the challenge of caching personalized or segmented content without session contamination. By using Advanced Cache Keys, you can store multiple variants of the same URL and deliver the right content to the right user.

Combined with Micro Caching for freshness and Tiered Caching for distribution, Granular Caching enables sophisticated caching strategies that maintain both performance and personalization.

Next steps

Check out Azion’s Cache solution and see how it implements Advanced Cache Keys for granular content delivery.

Talk to an Azion specialist