Cache-Aside
The app reads through the cache and fills it on a miss.
StarterData
The application checks the cache first; on a miss it reads the database, then populates the cache for next time. The cache holds only what has actually been requested.
When to use it
- Read-heavy workloads with a hot subset of frequently accessed keys
- The cache does not need to be pre-warmed with everything up front
Trade-offs
- First request for any key always pays the full database latency
- Needs an explicit invalidation strategy or stale reads will persist past TTL
Components used
Managed App ServiceCacheRelational Database
How it works
- The application checks the cache first. On a hit it returns immediately; on a miss it reads the database, writes the value into the cache, then returns it.
- The cache is entirely passive — it never talks to the database. All population logic lives in application code.
- Writes typically invalidate the cached key rather than updating it, letting the next read repopulate.
Used in the wild
- Read-heavy workloads with a clear hot subset, such as product pages or user profiles.
- Expensive computed results that are cheap to recompute occasionally but costly on every request.
- The default first caching strategy for almost any application — it is simple and fails safe.
Good to know
- It is resilient by construction: if the cache goes down, every request simply becomes a miss and hits the database. Slow, but still correct.
- Its classic failure is the cache stampede — a popular key expires and a thousand concurrent requests all miss and all hit the database at once. Request coalescing or jittered TTLs are the standard fix.
Related patterns
Retrieval-Augmented Generation (RAG)
Ground an LLM's answers in retrieved, up-to-date, private documents.
Vector Search + Rerank
Cheaply retrieve a broad candidate set, then precisely re-rank the top results.
Feature Store
Compute features once, serve them consistently to training and inference.
CQRS
Separate models and stores for writes and reads.