Cache invalidation
Change cache formats without breaking older application instances
Rolling releases can read and write the same cache at once. Separate incompatible formats and plan the load created when the new namespace starts empty.
In this article
Identify the shared value contract
Suppose an application changes a cached product value from a flat object to a nested pricing structure. New code may read the new format correctly while an older instance still expects a numeric price at the top level.
The cache has become an interface between deployments. Treat its stored shape as a contract even if no external client sees it.
List all writers and readers, including jobs, administrative tools and rollback versions. A background worker running yesterday's build can keep writing the old shape after the web deployment appears complete.
Introduce an explicit namespace
Use a new key namespace for an incompatible value shape. New instances read and populate the new namespace while older instances continue using the previous one.
Keep business invalidation effective for every namespace still serving traffic. Otherwise an update may clear the new entry while an old instance continues serving an unchanged copy.
Do not dual-write values without defining conversion and failure handling. A partially successful write can leave formats disagreeing. Where the cache is disposable, loading each namespace from the authoritative source may be simpler than maintaining a second write protocol.
Plan the cold-start load
Estimate how many distinct entries the new deployment will request and how expensive their source reads are. A small canary may have a poor hit rate because it sees little repeated traffic, while a full rollout may concentrate many simultaneous misses.
Limit concurrent loads and consider warming a measured set of high-demand, safe entries. Warming every possible key can waste resources and load data nobody will request.
Observe database latency, error rates and cache memory while both namespaces coexist. The deployment may temporarily need more memory even if the final format is smaller.
Keep rollback viable
Test the previous application version against its namespace after new code has run. Confirm that recent business changes remain visible under its invalidation policy.
Remove the old namespace only after old readers are gone and the rollback strategy no longer depends on it. Expiry can clean up residual entries, but it does not identify forgotten writers.
Document the format transition and the resource limits used during rollout. The next deployment should not have to rediscover that an apparently internal cache change can affect every running version of the application.
Primary sources
Microsoft: cache-aside patternReferences checked 11 September 2026.