Cache-Aside with Redis Primitives

## What cache-aside is Cache-aside (also called lazy loading) is the pattern where the **application code** orchestrates the cache. Redis is a dumb key-value store here: it does not know about your database and will never load anything by itself. The application asks Redis first, and only on a miss does it go to the system of record and then put the result back. The contrasting patterns — read-through and write-through — put the loading logic *inside* the cache layer, which requires a cache that can call your data source. Plain Redis cannot; a client library or a framework abstraction (for example a Spring `@Cacheable`-style layer) can make it *look* read-through, but underneath it is still emitting the same GET/SET pair. ## The concrete command sequence ``` GET product:v1:915 -> (nil) # miss <load row from Postgres, serialize to JSON> SET product:v1:915 "{...}" EX 300 # write back with TTL GET product:v1:915 -> "{...}" # subsequent hit ``` That is the whole mechanism. The interesting parts are the details around it. ## Why `SET ... EX` and not `SET` then `EXPIRE` `SET key value EX 300` is one command, so it is atomic: the key never exists without its expiry. If you write `SET key value` followed by `EXPIRE key 300`, the process can crash, the connection can drop, or a failover can happen between the two, and you are left with a key that never expires. Over months that produces a slowly growing population of immortal, stale entries that only `maxmemory` eviction will ever remove. `SET` has accepted `EX`/`PX` since Redis 2.6.12; there is no reason to use the two-command form. Related options worth knowing: `SET ... KEEPTTL` (6.0) overwrites the value while preserving the remaining TTL, and `GETEX key EX n` (6.2) reads and re-arms the expiry in one round trip if you want a sliding window. ## A miss is a normal outcome Juniors often treat `nil` as an error condition. It is not. On a cold start every read is a miss; after eviction or invalidation, misses reappear. What matters is that the miss path is correct and bounded: it must produce a value, write it back, and return it. Two consequences follow. First, **the database must be able to survive your miss rate**, because the miss path is just normal database load. Second, **an unbounded stream of misses for keys that will never exist** — the classic "look up a product ID that does not exist" probe — bypasses the cache entirely. The standard fix is to cache the negative result too: store a sentinel value (an empty marker) with a short TTL, so repeated lookups for a nonexistent row are answered from Redis. Be explicit about the sentinel so you can distinguish "cached: does not exist" from "not cached". ## Redis failure must not become application failure Because the cache is an optimization and the database is the truth, a Redis timeout, connection error, or `MOVED`-storm during a resharding event should be caught and treated as a miss. Set aggressive client timeouts (single-digit to low-double-digit milliseconds is typical for a cache) so that a struggling Redis does not become the latency of your request path. The inverse failure — the application refusing to serve because the cache is down — is a self-inflicted outage and is the single most common design mistake in this pattern. It is worth stress-testing the reverse case too: if Redis is emptied, every request becomes a database request at once. The read path above is what you exercise in that drill. ## What the value contains The cached payload should be whatever the caller actually needs, serialized once. Caching a half-assembled object that requires three more database queries to be usable defeats the point. Conversely, caching a giant aggregate that changes on any of twenty different writes makes invalidation nearly impossible. The unit of caching should match the unit of change and the unit of consumption. ## Freshness expectations Cache-aside is eventually consistent by construction. Between the moment a row changes and the moment the corresponding key is invalidated or expires, readers see stale data. The TTL is the backstop that bounds that staleness even when explicit invalidation is missed — a network blip, a crashed worker, a code path that forgot to invalidate. Design the read path assuming invalidation will sometimes be lost, because it will.