Caching Strategies
Concept
There are five common strategies for how an application's cache sits relative to its database, split by read path and write path:
- Cache-Aside (Lazy Loading) — the application checks the cache first; on a miss, it reads from the database and writes the result into the cache itself. The cache is passive — it never talks to the database directly.
- Read-Through — same miss behavior as cache-aside, but the cache library/layer owns the database read, not the application code.
- Write-Through — every write goes to the cache and the database together, synchronously, before the write is acknowledged. Strong consistency, slower writes.
- Write-Back (Write-Behind) — the write is acknowledged as soon as it hits the cache; the database write happens asynchronously afterward. Fast writes, but data can be lost if the cache fails before it flushes.
- Write-Around — the write goes straight to the database, skipping the cache entirely. Often paired with cache-aside so the cache only fills with data that's actually been read.
Tradeoffs
| Strategy | Write latency | Consistency risk | Failure mode |
|---|---|---|---|
| Cache-Aside | N/A (read-path only) | Stale cache until next read-miss | Cache down → falls back to DB, just slower |
| Write-Through | Slower (waits on both) | Strong | DB down → write fails outright |
| Write-Back | Fastest | Weakest | Cache dies before flush → data loss |
| Write-Around | Fast (DB only) | First reads always miss | Cold-read penalty right after a write |
The core tension is always the same triangle: write latency vs. consistency vs. durability — you can't maximize all three with one strategy, which is why production systems usually combine two (e.g., write-around + cache-aside together, so the cache stays a pure read-optimization layer and never becomes a second source of truth).
When to use / when not to
- Cache-aside is the default for read-heavy workloads that can tolerate slightly stale data (product catalogs, user profiles).
- Write-through earns its cost when reads immediately after a write must be correct (e.g., a user's own settings page reloading right after they hit save).
- Write-back fits high write-volume, latency-sensitive paths where occasional loss is acceptable or mitigated elsewhere (metrics counters, non-critical logs) — rarely justified for anything transactional.
- Write-around fits write-once-read-rarely data (audit logs, cold historical records) where warming the cache on write would just evict genuinely hot data.
Common pitfall
Treating the cache as a second source of truth instead of a derived, disposable view of the database. The moment a system can't survive a full cache flush without data loss or corruption, the caching strategy has quietly become a consistency bug waiting for a cache eviction storm or restart to expose it.
Engineering Lens
This is one of the fastest tells in a design review of whether someone has actually operated a cache in production versus only read about it. The strong answer is never "which strategy is best" — it's "which strategy fits this specific read/write ratio and this specific tolerance for staleness," stated as an explicit tradeoff, not a default. Being able to name the failure mode of your chosen strategy before someone asks about it is what reads as Principal-level ownership, regardless of what stack or industry it's applied in.