Cache-aside
With cache-aside, the application checks the cache and loads from the authoritative store on a miss.
- Cache hitEntry exists.
- Cache missRead database and populate cache.
- Write changeDefine expiry or invalidation.
Context
Why this is important
Use cache-aside for repeated reads with an explicit freshness rule.
Read strategy with application-managed population, expiry and invalidation.
Cache-aside: hit, miss and invalidation
The Catalog module caches product reads; stock and price changes need suitable refresh rules.
This is how you read the picture
- Cache hit direct response
- Cache miss load through
- Write change Freshness
| Aspect | Meaning | Validation |
|---|---|---|
| Read | Check cache first. | Load miss from source. |
| Write | Update source. | Refresh cache deliberately. |
Benefits & limitations
Helps if:
- Repeated reads can be served from a cache.
- The application needs to control population and invalidation.
Boundaries
- Cache and source can temporarily contain different values.
- A cache outage or concurrent misses can add load and latency.
In practice
- Define the key, source of truth, expiry and tolerable staleness for the query. Avoid deriving cache keys from unvalidated input.
- Implement hit and miss paths separately and decide how entries are invalidated or refreshed after changes. Limit concurrent refreshes when many requests miss the same entry.
- Test misses, stale values, cache failures and concurrent initial queries; measure load and hit rate against the database.
Read the detailed explanation
On a hit, the application uses the cached value. On a miss, it reads the authoritative store, writes the value to the cache with an expiry and returns it. Write paths update the source first; cache invalidation or repopulation needs a defined rule.
Cache-aside is a read strategy that keeps the cache outside the source of truth. Stale data, stampedes, cache failures and negative caching must fit business freshness needs.
Cache-aside is a caching strategy; data ownership determines the source of truth on a miss.
Data ownership determines which source remains authoritative on a miss.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
What happens on a cache miss?
View the solution with justification
The application reads the database and populates the cache.
ApplyingTransferred to a new situation
How does an updated product price become visible?
View the solution with justification
The Catalog module invalidates or refreshes the affected cache entry.
EvaluateWeighing an alternative
When is brief staleness unacceptable?
View the solution with justification
When the business rule requires current values, such as authoritative price or stock validation.
Explore further
These building blocks continue the thoughts of this page.
References
- Microsoft · Cache-Aside pattern (opens in new tab)Primary documentation for cache-aside flow and invalidation.
- AWS Well-Architected · Caching (opens in new tab)Architecture guidance for caching in data access patterns.
- Google Cloud · Memorystore for Redis (opens in new tab)Documentation for operating a managed caching service.