Caching Strategies

A cache sits between an application and the data store it's slow to query directly, and the simplest way to use one is cache-aside, sometimes called lazy loading. AWS's own documentation on ElastiCache caching strategies describes the flow plainly: the application asks the cache first; on a hit, the cache returns the data directly; on a miss, the application queries the backing store itself, then writes the result into the cache before returning it, so the next request for that key is a hit. Nothing is loaded into the cache until something actually asks for it, which keeps the cache small and relevant to real traffic — but it also means a cache that was just cleared (deployed, restarted, evicted under memory pressure) starts genuinely cold, and the first wave of requests after that pays the full backing-store cost.

Cache-aside has a specific weakness AWS's documentation names directly: because the cache is only populated on a read miss, nothing updates it when the underlying data changes through a different path, so a value already sitting in the cache can quietly go stale until it expires or is evicted. Write-through closes that gap by writing to the cache at the same time as the backing store, so a cache entry is never allowed to fall behind — the cost is that every write now pays for two operations instead of one, and any key nobody has read yet still isn't in the cache until it's requested (or pre-warmed). The two aren't mutually exclusive: a design commonly uses cache-aside for the bulk of its reads and adds write-through, or a short TTL, specifically on the fields that can't tolerate staleness.

The choice tracks the read/write ratio estimated earlier. A read-heavy path — a product page, a user profile — gets most of its value from cache-aside alone: most requests are reads, most of those reads hit the cache, and the rare write can simply let the stale cached copy expire on its own TTL. A path where reads need to reflect a write almost immediately — an inventory count right before checkout — needs write-through, or an explicit invalidation on write, because waiting out a TTL risks selling something that's already gone. Naming which fields fall into which category, out loud, is the same move as naming a non-functional requirement: it turns "we added a cache" into a decision an interviewer can evaluate.