Caching Strategies (Cache-Aside/Write-Through/Write-Back)
Overview
A caching strategy defines how an application keeps a fast, temporary copy of data in a cache and how that copy stays in step with the underlying data store. The four core patterns are cache-aside, write-through, write-back, and write-around, and each strikes a different balance between read latency, write latency, and staleness.
Key Concepts
A cache sits between the application and the source of truth, which is usually a database. A read that finds its data in the cache is a cache hit; a miss falls through to the database. The strategy you pick decides who populates the cache and when writes reach the data store.
Cache-aside
Also called lazy loading. The application checks the cache first; on a miss it loads from the database, stores the result in the cache, then returns it. Writes go to the database and invalidate the cached key. Only requested data is ever cached, so the cache stays lean, but the first read of any key always misses.
Write-through
Every write updates the cache and the database synchronously in one operation. The cache is always consistent with the database and reads after a write are guaranteed fresh, at the cost of higher write latency because two stores sit on the critical path.
Write-back
Also called write-behind. Writes land in the cache and are acknowledged immediately, then flush to the database asynchronously, often in batches. This gives the lowest write latency and absorbs write bursts, but a cache failure before a flush can lose data.
Write-around
Writes bypass the cache and go straight to the database; the cache is filled only on a later read miss, usually paired with cache-aside reads. This keeps write-heavy data that is rarely read from crowding out hot keys.
| Strategy | Write path | On read miss | Read freshness | Best for |
|---|---|---|---|---|
| Cache-aside | DB only, invalidate key | App loads and populates cache | Can be stale until invalidation | Read-heavy, general purpose |
| Write-through | Cache and DB together | Rare (cache pre-filled) | Always fresh | Read-heavy, low staleness tolerance |
| Write-back | Cache now, DB later | Served from cache | Fresh in cache | Write-heavy, bursty writes |
| Write-around | DB only | App loads and populates cache | Fresh after first read | Write-heavy, rarely re-read data |
When a cache fills up, an eviction policy decides which entries to drop. Caching also happens at the network edge through a content delivery network.
Trade-offs
The central tension is read freshness versus write cost versus durability. Cache-aside is resilient because a cache outage only slows reads, but it tolerates staleness between a database write and the cache invalidation. Write-through keeps reads fresh yet pays two writes on every update and may cache data that is never read again. Write-back wins on write throughput but risks losing unflushed data and adds complexity around flush ordering and retries. Write-around keeps the cache clean for read-heavy keys but makes freshly written data slow on its first read.
| Strategy | Main benefit | Main cost |
|---|---|---|
| Cache-aside | Resilient, caches only what is used | Cold-start misses, possible staleness |
| Write-through | Always-consistent reads | Higher write latency |
| Write-back | Fastest, batch-friendly writes | Data-loss window on cache failure |
| Write-around | Avoids cache pollution | Slow first read of new data |
Interview Tips
- State the read/write ratio first, then justify the pattern: cache-aside is a safe default for read-heavy systems.
- Address invalidation explicitly, because interviewers expect to hear either a time-to-live (TTL) or an explicit invalidation plan rather than a hand-wave.
- Call out the data-loss window in write-back and pair it with database replication when durability matters.
Summary
- A caching strategy decides who populates the cache and when writes reach the data store.
- Cache-aside loads lazily on a miss and is the default for read-heavy systems.
- Write-through writes cache and database together for always-fresh reads at higher write cost.
- Write-back acknowledges at the cache and flushes later for speed, risking data loss.
- Write-around skips the cache on writes to protect hot keys from eviction.
- Choose from the workload's read/write mix and its tolerance for staleness.