It's 9:00 AM on the first day of a big sale. Within seconds, thousands of shoppers open the same 50 product pages in an online retail store. Every page view runs the same joins, the same price lookups, and the same stock-level check. The database ends up answering the same question, say, 40,000 times a minute.
A cache fixes this. When data is read far more often than it changes, serving it from memory takes the repeat work off your database, lowers latency, and keeps response times steady during traffic spikes.
To help you get started, we've published caching pattern architectures, how-to guides, and sample code that pair Azure Managed Redis with Azure Database for PostgreSQL, Azure SQL Database, and Azure Cosmos DB. The patterns work with any database. All three samples build the same online retail store, so you can see which caching pattern fits each feature and how the implementation changes from one database to the next.
Why add a cache if your database already has one?
Each of these databases caches data in memory. PostgreSQL has its buffer cache, Azure SQL Database has its buffer pool, and Azure Cosmos DB has fast point reads plus an optional integrated cache. But a built-in cache shares memory with the database's own work, and it's tied to the database's servers. Azure Managed Redis runs outside the database and gives your application:
- Sub-millisecond reads for hot data. Popular product pages, menus, and configuration come straight from memory.
- Fewer expensive queries. One key lookup replaces a multi-table join and aggregate. On Azure SQL Database and PostgreSQL, that saves CPU, workers, and IOPS. On Azure Cosmos DB, it absorbs hot reads and frees throughput for the queries that need it.
- Room to grow without scaling up. A cache can absorb a traffic spike that would otherwise push you to a bigger compute tier.
- Data structures that databases don't provide efficiently. Counters, sorted sets for rankings, rate limits, and session state.
- Control over what's cached. You choose what to cache and for how long, and one cache can serve every service in your app.
The database stays the source of truth. Azure Managed Redis holds copies of the data your app reads most, and the patterns below keep those copies fresh.
Caching patterns, explained with an online retail store
Each feature of the store reads and writes data differently, so each one needs its own caching pattern.
| Caching pattern | How it works | Example store feature |
|---|---|---|
| Cache-aside | Check Redis first. On a miss, read the database and cache the result with a time to live (TTL). It's the most common pattern, and the easiest place to start. | Product pages that many shoppers view |
| Reference-data prefetching | Load stable data that every page needs into the cache up front, and refresh it when the source changes. | Categories, tax rates, and shipping options used on every page |
| Write-through | Commit the change to the database, then write the new value to the cache, so shoppers see it right away. | Price and stock updates your app makes |
| Event-driven updates | When another system changes the data, such as the warehouse, a listener picks up the change and updates or removes the cached copy. | Order status that the warehouse updates as orders ship |
| Write-behind | Count in Redis right away, then write the totals to the database in batches. Use it where losing a few increments is acceptable. | View counters that update on every page visit |
| Sorted-set ranking | A Redis sorted set keeps items in order by score, so rankings are ready to read instead of recomputed on every request. | Best-seller and top-rated product lists |
| Session and state offload | Keep short-lived state that changes on every request in Redis, off your system of record. | Shopping carts and sign-in sessions |
| Multi-region caching | Active geo-replication keeps a cache in each region in sync, so shoppers read from a nearby cache. | A storefront that serves shoppers in many regions |
Architectures, guides, and sample code
Most apps combine several of these patterns, one for each kind of data. In the online retail store, product pages use cache-aside, prices use write-through, and orders use event-driven updates.
Caching pattern architectures
The Azure Architecture Center covers three of these patterns, each with a diagram, data flow, components, reliability, security, and cost considerations. Each one uses one database as an example, and the same design works with any of the three databases:
- Cache-aside: Azure Managed Redis + Azure Database for PostgreSQL
- Write-through: Azure Managed Redis + Azure SQL Database
- Event-driven updates: Azure Managed Redis + Azure Cosmos DB
How-to guides
Microsoft Learn has a guide for each database that explains which patterns fit and how to implement them:
Sample code
The amr-caching-pattern-samples repository builds the same online retail store on three databases. Together, the samples cover seven of the eight patterns:
| Caching pattern | Azure Database for PostgreSQL | Azure SQL Database | Azure Cosmos DB |
|---|---|---|---|
| Cache-aside | ✅ | ✅ | ✅ |
| Reference-data prefetching | ✅ | ✅ | ✅ |
| Write-through | ✅ | ✅ | ✅ |
| Event-driven updates | ✅ Redis Streams worker | ✅ Azure Functions SQL trigger | ✅ Change feed with Azure Functions |
| Write-behind | ✅ | ||
| Sorted-set ranking | ✅ | ||
| Session and state offload | ✅ |
The samples don't cover multi-region caching, because each sample deploys to a single region. To keep caches in several regions in sync, see Configure active geo-replication.
Deploy a sample
-
Install the Azure Developer CLI (azd) and the Azure CLI, then sign in with
az loginandazd auth login. -
Clone the samples, pick a database, and deploy. Use a different azd environment name for each sample so one deployment doesn't overwrite another.
git clone https://github.com/AzureManagedRedis/amr-caching-pattern-samples cd amr-caching-pattern-samples/azure-sql-retail-sample # or postgres-retail-sample, cosmos-db-retail-sample azd env new <your-env-name> azd up -
Open the storefront and follow the walkthrough in the sample's README to see each pattern in action.
-
The samples deploy Azure resources that bill while they run. When you're done, run
azd down --purge --force.
Best practices for caching
- Cache what's read often and changes rarely. Product pages, menus, prices, and lookup tables are great candidates. Write-heavy data with little reuse usually isn't.
- Set TTLs by how much staleness your business can accept. Ask how stale a value can be before it causes a problem, then set the TTL to match. Add a little random jitter so many keys don't expire at the same moment.
- Treat the cache as an optimization. If the cache is unavailable, the app should fall back to the database. Build in retry logic for both services.
- Put everything in the same region. Co-locate your app, Azure Managed Redis, and your database to avoid extra network round trips.
- Use Microsoft Entra ID instead of access keys. Every sample uses
DefaultAzureCredentialfor both Azure Managed Redis and the database. In Azure, it uses the app's managed identity. On your machine, it uses your developer sign-in, such as the Azure CLI. Either way, there are no secrets in your code or configuration. To learn more, see Use Microsoft Entra for cache authentication with Azure Managed Redis. - Watch the right numbers. Track cache hit ratio, evictions, and latency on the Redis side, and CPU, workers, IOPS, or RU/s on the database side. A low hit ratio or high evictions usually means TTLs are too short or the cache is too small for your working set.
Learn more
- New to Azure Managed Redis? Read the overview and create your first instance.
- Want a real-world example? Learn how Sitecore builds to scale on Azure Managed Redis.
Have a database or pattern you'd like us to cover next? Tell us in the comments, or open an issue in the samples repository. We'd love to see what you build.
Microsoft