PopulationStrategies ReadThrough WriteThrough WriteBehind WriteAround
How the cache and the source of truth actually stay in sync: cache-aside (app populates on miss), read-through (cache populates itself transparently), write-through (write to cache+DB together), write-behind (write to cache now, DB later, async), write-around (write straight to the DB, skip the cache entirely, only populate on a later read).
Why we need this / what value this brings
Picking the wrong sync strategy trades off write latency, cache pollution, and staleness risk differently — getting it wrong means either slow writes, a cache full of data nobody re-reads, or a window where the cache lies.
When to use this
Cache-aside/read-through for read-heavy data where a miss is cheap to absorb; write-through when the cache must never be stale; write-behind only when write latency matters more than the small risk of losing an unflushed write; write-around for write-once, rarely-immediately-reread data that would otherwise pollute the cache for no benefit.
How to use or implement this
Default to cache-aside (simplest, most explicit); reach for write-through only where staleness is unacceptable, write-behind only after accepting its crash-loss risk, and write-around when a write-through/write-behind cache would just fill up with data nobody's about to read.
Research questions
- Cache-aside vs read-through: functionally similar, but who owns the miss-handling logic — the app, or the cache layer itself?
- Write-behind's risk window: what happens to in-flight writes if the cache node crashes before flushing to the DB?
- Write-around avoids caching data that's written once and rarely re-read soon after — when does that fit Localz (e.g. a booking's initial write vs its frequently-read status)?
Empty folder — drop notes, links, and findings here as you research.