Cache-aside (lazy loading).

When the application needs data, it follows one sequence. Check the cache first: query Valkey for the key with GET. On a hit: return the cached value immediately. On a miss: query the primary database, write the result back to Valkey with a TTL, then return it. The key insight is that the application populates the cache — Valkey never fetches from the database on its own.

Two moves define the pattern. On a read: GET, and on a miss read the source then SET … PX the value with an expiry. On a write to the source: DEL the cached key so the next read re-fills it. The cache is a disposable copy of a source of record; nothing keeps the two in lockstep, and the pattern bounds the lag with a TTL.

A typical cache-aside flow uses three commands — a read, a fill with an expiry, and an invalidation. The key is EchoCache’s own keyspace, ecc:{<table>}:<id> (EchoCache.Keyspace.key/2), with the table name hash-tagged so one cache lands in one cluster slot:

Set the value and the TTL in one command; a separate EXPIRE after SET leaves an immortal key if the process dies between the two. In EchoCache the read surface is one function: EchoCache.Table.fetch/3 returns {:ok, value, source} with source :hit | :l2 | :fill — an L1 ETS hit in the caller’s process, an L2 Valkey hit, or a loader fill. The functional-Elixir craft behind the echo data layer is taught by the /elixir state chapter; this module is the cache placed in front of the source.

• Resilience to cache failure. If Valkey becomes unavailable, the application degrades gracefully to the database. Latency rises; the system stays functional.
• Memory efficiency. Only data that is actually requested gets cached, so the working set is demand-shaped and unused data does not occupy cache memory.
• Simplicity. The pattern is straightforward to implement and reason about.

The primary disadvantage is stale data. A reader takes a cache hit; another process updates the row in the database; the cached copy stays unchanged until the TTL expires. The cache now holds outdated information, for up to the remaining TTL.

The cost of avoiding that round trip is what makes the trade worth managing. EchoCache’s committed record measures it: an L1 hit reads in 762 ns against 31 us per L2 GET on the same wire — the hit is 40 times cheaper than the round trip it replaces.

The standard mitigation is cache invalidation on write: when the application updates the source, it immediately deletes the cached key with DEL. The next read misses and fetches fresh data. Deleting is simpler and safer than updating the cache in place, which risks a race — two set-on-write writers can interleave and leave the older value in place indefinitely, whereas delete-on-write is wrong for at most one TTL. The TTL is therefore a correctness bound, not a memory knob. In EchoCache the unconditional admin verb is Table.invalidate/3 — a DEL on L2 plus an :ets.delete on L1, dropping one name from both layers.

Use cache-aside when the workload is read-heavy, brief staleness is acceptable, graceful degradation on cache failure is wanted, and fine-grained control over what gets cached is needed.

Avoid it when strong consistency between cache and database is required, write-then-immediately-read is common (the read may hit a stale cache), or the cost of a single cache miss is extremely high.

Each dive takes one of the three problems cache-aside has to get right, in the arc fill → invalidate → bound: how a miss fills the cache, how a write clears it without resurrecting a stale value, and how a TTL backstops a missed invalidation. Read them in order — the read path starts.