Partial caching
Outline
- What it is: Caching reusable fragments like blocks and product cards.
- Why it matters: Reduces rendering time and server load.
-
Core APIs:
IMemoryCache,IDistributedCache,OutputCache. -
Optimizely advantage:
IContentCacheKeyServiceenables smart invalidation. - DXP rule: Use distributed caching in multi-node environments.
This module provides a technical deep dive into partial (fragment) caching within ASP.NET Core-based Optimizely solutions, covering in-memory and distributed caching patterns with practical implementation examples.
1. In-Memory Caching (IMemoryCache)
IMemoryCache stores cached data in the memory of the running process. It is suitable for single-node deployments but should not be used in multi-node DXP environments where cache entries would be inconsistent across instances.
Registration (Program.cs)
Usage in a Service
Important: IMemoryCache is process-local. In a multi-node DXP environment, each server maintains its own independent cache, meaning updates on one node will not invalidate cached entries on others. Use IDistributedCache instead.
2. Distributed Caching (IDistributedCache)
IDistributedCache stores cached data in a shared external store such as Azure Cache for Redis, making it consistent across all nodes in a multi-server deployment. This is the correct approach for DXP environments.
Registration with Redis (Program.cs)
Async Usage in a Service
Pro tip: The IDistributedCache API works with raw byte arrays. Pair it with a serialization helper (JSON, MessagePack, or Protobuf) to avoid scattering Encoding.UTF8 calls throughout your services. A thin generic wrapper such as ICacheService<T> keeps things consistent and testable.
