The problem
When exactly do you write to the cache vs the database? Get it wrong and you serve stale or lose data.
The idea
Three common patterns trade freshness against speed and durability.
How it works
Cache-aside: the app reads cache, on miss loads the DB and fills the key; writes go to the DB and invalidate the key (not update it). Write-through: writes hit cache and DB synchronously — fresh, slower writes. Write-back: writes land in cache and flush to the DB later — fastest, but a crash loses the unflushed window. The subtle bug is the cache-aside race: a reader fills a stale value just as a writer invalidates, leaving the cache wrong until the next write.
The tradeoff
Cache-aside is simplest and most common but carries a stale-read window and that fill/invalidate race (mitigate with short TTLs or versioned keys). Write-through keeps cache and DB in lockstep at write-latency cost. Write-back trades durability for speed. Prefer invalidating over updating the cache — updating re-introduces the dual-write consistency problem.
In the wild
Most web apps use cache-aside with Redis + a TTL.
Deep dive
Flow
- Read: check cache; on miss load DB and populate with a TTL.
- Write: update the DB, then invalidate the key (don't update it).
- Next read repopulates the cache from the source of truth.
- Keep a TTL as a backstop against missed invalidations.
Watch for
- Updating the cache on write re-creates a dual-write race.
- Cache-aside has a fill-vs-invalidate race — short TTL or versioned keys help.
- Write-back loses the unflushed window on a crash.
Common trap
Default to cache-aside + invalidate + TTL, and name the stale-read window you accept.
Common questions
What problem does Cache-aside, write-through, write-back solve?
When exactly do you write to the cache vs the database? Get it wrong and you serve stale or lose data.
How does Cache-aside, write-through, write-back work?
Cache-aside: the app reads cache, on miss loads the DB and fills the key; writes go to the DB and invalidate the key (not update it). Write-through: writes hit cache and DB synchronously — fresh, slower writes. Write-back: writes land in cache and flush to the DB later —…
What are the tradeoffs of Cache-aside, write-through, write-back?
Cache-aside is simplest and most common but carries a stale-read window and that fill/invalidate race (mitigate with short TTLs or versioned keys). Write-through keeps cache and DB in lockstep at write-latency cost. Write-back trades durability for speed. Prefer invalidating…
Where is Cache-aside, write-through, write-back used in production?
Most web apps use cache-aside with Redis + a TTL.