Caching Strategies

When You Need Caching Strategies

Choosing the wrong caching strategy leads to stale data, cache misses, or unnecessary database load. In interviews, you must justify which strategy fits your system's read/write patterns.

What It Is

Caching strategies define how data flows between the cache and the database. The main patterns are: Cache-Aside (Lazy Loading), Read-Through, Write-Through, Write-Behind (Write-Back), and Write-Around. Each has different tradeoffs for consistency, latency, and complexity.

How It Works

For a read-heavy social media feed: Use Cache-Aside. When a user loads their feed, check Redis. If cached, return immediately. If not, query the database, store in Redis with 5-minute TTL, return. When a new post is created, invalidate the cached feed.

For a write-heavy IoT system: Use Write-Behind. Sensor data is written to Redis (fast), then a background process flushes to the database in batches (efficient). But if Redis crashes, unflushed data is lost.

The Decision Framework

• Cache-Aside (Lazy Loading): Application checks cache first. On miss, reads from DB, writes to cache. Most common strategy. Simple, but first request always misses.
• Read-Through: Cache itself fetches from DB on miss. Application only talks to cache. Simplifies application code.
• Write-Through: Every write goes to cache AND database synchronously. Guarantees cache is always fresh. But adds write latency.
• Write-Behind (Write-Back): Writes go to cache first, then asynchronously to database. Fast writes but risk data loss if cache crashes.
• Write-Around: Writes go directly to database, bypassing cache. Avoids cache pollution for write-heavy data. But first read always misses.

What the Industry Uses

Facebook uses Cache-Aside with Memcached — the application manages cache reads and writes explicitly.

Amazon DynamoDB Accelerator (DAX) is a Read-Through cache — the application queries DAX, which handles cache misses transparently.

MySQL InnoDB Buffer Pool is essentially a Write-Behind cache — changes are buffered in memory and flushed to disk asynchronously.

Performance and Tradeoffs

• Cache-Aside: Simple, flexible. But application must manage cache explicitly. Cold start problem.
• Write-Through: Cache always fresh. But slower writes.
• Write-Behind: Fastest writes. But risk of data loss. Complex.
• Read-Through: Simpler application code. But less control over caching logic.

Mistakes Engineers Make

1. Not invalidating cache after writes — leads to stale data
2. Using Write-Behind without understanding the data loss risk
3. Not handling the thundering herd on cache miss

Practice These Interview Questions

1. What are the main caching strategies?
2. When would you use Write-Through vs Write-Behind?
3. How do you handle cache invalidation in Cache-Aside?
4. What is the risk of Write-Behind caching?

Original DosiBridge notes for Caching Strategies

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Caching Strategies is to connect the concept to a traffic-management problem where overload behavior matters more than the happy-path diagram. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Freshness Window: For Caching Strategies, decide the freshness window before choosing tools; otherwise the design looks clean but fails when caching changes.
• Eviction Pressure: For Caching Strategies, decide the eviction pressure before choosing tools; otherwise the design looks clean but fails when strategies changes.
• Hot Key Behavior: For Caching Strategies, decide the hot-key behavior before choosing tools; otherwise the design looks clean but fails when caching changes.
• Cache Stampede: For Caching Strategies, decide the cache stampede before choosing tools; otherwise the design looks clean but fails when strategies changes.
• Invalidation Owner: For Caching Strategies, decide the invalidation owner before choosing tools; otherwise the design looks clean but fails when caching changes.

Production review question

If a team adopts Caching Strategies, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track caching-strategies health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Caching Strategies, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.

Further Reading

• Caching
• cache-eviction-policies
• Distributed Caching
• read-through-vs-write-through-cache