Cache-Aside

Cache-Aside (also called lazy loading) keeps a cache beside the application and the system of record. The application is responsible for loading data into the cache and keeping it consistent with the underlying store. The cache itself has no knowledge of the data store, which keeps the caching concern firmly inside the application.

The problem it addresses is the cost of repeatedly reading the same data from a relational database, object store, or remote service. Such reads can be slow, expensive per request, or limited by connection and throughput caps. A cache such as Redis, Memcached, or a managed service like Azure Cache for Redis or Amazon ElastiCache serves hot data from memory in microseconds, cutting latency and offloading the backing store so it can devote capacity to writes and uncached reads.

How It Works

On a read, the application first checks the cache. On a hit, it returns the cached value. On a miss, it reads from the data store, writes the value into the cache, and returns it. Subsequent reads are served from the cache until the entry expires or is evicted.

Writes go to the data store. To avoid serving stale data, the application either updates the cache after the write or, more commonly, invalidates (deletes) the cache entry so the next read repopulates it. Entries carry a time-to-live (TTL) so even un-invalidated data eventually refreshes.

When to Use It

Use it for read-heavy data that changes infrequently and where some staleness is acceptable: product catalogs, user profiles, reference data, and computed results. It works best when the same keys are read repeatedly.

Avoid it for data that must always be current to the millisecond, for write-heavy datasets with little reuse, and for data whose access pattern is uniformly random (low hit ratio).

Trade-offs

The main risk is consistency: between a write and the corresponding cache invalidation, readers may see stale values. Cold starts are slow because the first read of each key misses. A cache stampede can occur when many requests miss the same expired key at once and all hit the store; mitigations include request coalescing, locks, and staggered TTLs.

Memory is finite, so an eviction policy (LRU, LFU) is required. The cache adds an operational component to monitor and scale, and developers must place invalidation logic carefully to avoid subtle bugs.

Related Patterns

Cache-Aside complements the Materialized View pattern, which precomputes query-shaped data; the two are often combined. Index Table improves lookups in the backing store. For globally distributed caching, the Geode pattern places caches close to users.

Example

A web API receives a request for product 42. It calls GET product:42 on Redis. The key is absent, so the service queries PostgreSQL, retrieves the row, serializes it, and runs SET product:42 <json> EX 300 (a 5-minute TTL). The next request for product 42 is served from Redis. When an admin updates the product, the service writes to PostgreSQL and issues DEL product:42, forcing the next read to repopulate the cache with fresh data.