
Azure Managed Redis & Azure Cosmos DB with Cache-Aside (Blog Post)
Overview
This article lays out a production-minded cache-aside design: read from Redis first, fall back to Cosmos DB on a miss, then populate Redis with a TTL; on writes, update Cosmos DB and invalidate/refresh cache keys. It also highlights deterministic invalidation using Cosmos DB ETags, and cache refresh via the Cosmos DB Change Feed (e.g., an Azure Function) to keep hot keys warm under write bursts. The post includes a reference architecture and code examples (including Entra ID auth patterns) and frames the benefits in both performance terms (sub-millisecond cache reads) and cost terms (RU savings by offloading repeat reads).
Challenges & Solutions
Explaining consistency boundaries clearly (Redis as optimization, Cosmos as system of record).
Designing predictable invalidation/refresh mechanisms for real-world write patterns.
Providing guidance that’s operationally realistic (observability, co-location, capacity planning).
Outcomes
Delivered a reference implementation pattern that teams can adopt incrementally in a data access layer.
Documented concrete tactics (ETags + Change Feed) for keeping caches correct and effective at scale.