Write-around Cache

System Design FundamentalsSeniorcachingsystem-design

The Question

What is a write-around cache strategy?

What a Strong Answer Covers

• bypass cache on write
• contrast with write-through/write-back.

Senior-Level Answer

Write-around caching is a strategy in which write operations bypass the cache entirely and go directly to the persistent storage (database, object store). The cache is only populated on cache miss during a subsequent read. This contrasts with write-through (cache and storage updated synchronously on every write) and write-back (cache updated immediately, storage updated asynchronously).

**How it works**: On a write, the application writes directly to the backing store, leaving the cache untouched. If a cached entry for the same key exists, it is either left stale (to expire via TTL) or explicitly invalidated. On a subsequent read, a cache miss triggers a read from storage and a cache population.

**When to use it**: Write-around is optimal when written data is unlikely to be re-read in the near term. Classic use cases include: - **Log ingestion and analytics**: Log records are written once and read rarely or in bulk aggregate queries, not individually. - **Bulk imports / batch ETL**: Large volumes of data loaded into a database that won't be queried immediately don't benefit from cache population—they would evict hot entries. - **Media upload pipelines**: A newly uploaded video or image is written to object storage but rarely fetched in the seconds after upload.

**Advantages**: Prevents cache pollution—the cache is not filled with cold data that will never be re-read, preserving cache space for frequently-accessed data. Reduces write latency compared to write-through (only one write, to storage, not two).

**Disadvantages**: First reads after a write incur a cache miss penalty. If the same data is frequently read shortly after write (e.g., a user reading back a record they just created), write-around causes unnecessary latency. In those cases, write-through or application-level cache population on write is preferable.

**Comparison with write-through**: Write-through keeps the cache always warm for recently written data at the cost of double-write overhead. Write-around is cheaper on write but cold on immediate re-read. The choice depends on the read-after-write access pattern.

A hybrid approach: use write-around for bulk/background writes, but explicitly populate the cache for user-facing writes where read-after-write is the dominant pattern.

What Separates a 2/3 from a 3/3

Common Mistakes

• Confusing write-around with write-back (write-back writes to cache first, flushes to storage async; write-around skips the cache entirely).
• Not explaining the cache pollution problem that motivates write-around.
• Recommending write-around for workloads with high read-after-write patterns.
• Not mentioning that existing cache entries for the key should be invalidated on write to prevent stale reads.

Follow-Up Questions

• How does write-around prevent cache pollution, and why does that matter? — Write-around avoids filling the cache with cold data that consumes space and evicts hot entries, keeping the effective cache hit rate high.
• When would you choose write-through over write-around despite the double-write cost? — When the access pattern is write-then-read immediately (user creates a record and views it), write-through avoids the cache miss on that read.
• What happens if you use write-around but forget to invalidate the existing cache entry on update? — The cache serves a stale version of the record until TTL expiry, causing reads to return outdated data after the write.
• How would you implement a hybrid strategy for a social media post feed? — New post writes go write-around to avoid polluting feed caches with rarely-read content. The author's own feed read explicitly populates the cache for their immediate view.

Related Questions

• Redis Caching Patterns
• Vertical vs Horizontal Scaling
• API Versioning
• SLOs vs SLAs
• Availability — Five 9s