Summary
Read-heavy API workloads with a stable, point-lookup-dominated access pattern benefit from cache-aside: the working set fits in cache memory, hit rate stays high because the same keys are read repeatedly, and the application can tolerate a bounded TTL staleness window in exchange for sub-millisecond reads.
Evidence
- ·read_heavy_api recommends cache_aside directly (workloads/read_heavy_api.yaml recommended_patterns)
- ·read_heavy_api's point_lookup and range_scan access patterns match cache_aside's applicable_when condition of repeated access to the same keys (workloads/read_heavy_api.yaml, patterns/cache_aside.yaml)
- ·read_heavy_api's session consistency_requirement tolerates cache_aside's bounded TTL staleness window (workloads/read_heavy_api.yaml, patterns/cache_aside.yaml)
Operational Context
- ·Preferred over materialized_view when the data being read is not the output of an expensive aggregation or join, just a repeated point lookup — materializing a plain lookup wastes refresh cycles on a query that was already cheap
- ·Preferred over read_replica when the workload's read latency target is sub-millisecond — a replica still pays a full database query, just against a second node, while a cache hit skips the database entirely
Tradeoffs
- ·Introduces cache/database divergence risk (cache_stampede on mass expiry, stale reads within the TTL window) that neither materialized_view's scheduled-refresh staleness nor read_replica's replication-lag staleness present in the same shape
- ·Adds no read-scaling benefit for queries that miss the cache; unlike read_replica, a cache-aside miss still lands fully on the primary database
Evidence grounding
Grounded, 3 supporting itemsread_heavy_api already lists cache_aside as a recommended pattern (workloads/read_heavy_api.yaml); this relationship makes the underlying condition explicit rather than leaving the recommendation unexplained.