Caching Strategies

Placing a cache in your system is easy. Deciding how your application interacts with that cache is the hard part. The pattern you choose determines your data consistency, write latency, and system resilience.

1. Cache-Aside (Lazy Loading)

This is the most common pattern. The application is responsible for coordinating between the cache and the database.

Flow

1. Read: App checks Cache.
   • Hit: Return data.
   • Miss: App reads from DB -> App writes to Cache -> Return data.
2. Write: App writes to DB -> App invalidates/deletes Key in Cache.

Analysis

• Pros:
  • Resilient: If the cache fails, the system just acts as if every request is a "miss" and reads from the DB. It doesn't crash completely.
  • Data Model: Cache contains only what is actually requested (lazy), keeping it lean.
• Cons:
  • Stale Data: There is a small window between writing to DB and invalidating cache where users might read old data.
  • Thundering Herd: If a popular item expires, multiple processes might try to rebuild it simultaneously.

2. Write-Through

The cache sits in front of the database. The application treats the cache as the main data store.

Flow

1. Write: App writes to Cache -> Cache writes to DB (Synchronously).
2. Read: App reads from Cache.

Analysis

• Pros:
  • High Consistency: Cache and DB are always in sync.
  • No Stale Requests: Data in cache is never older than data in DB.
• Cons:
  • High Latency: Every write operation must do 2 writes (Cache + DB). This is the slowest write performance.
  • Cache Pollution: You might write data that is never read, wasting memory.

3. Write-Back (Write-Behind)

Similar to Write-Through, but the DB write happens asynchronously.

Flow

1. Write: App writes to Cache -> Cache immediately acknowledges success.
2. Sync: Cache asynchronously writes to DB in the background (after X seconds or X writes).

Analysis

• Pros:
  • Fastest Writes: The user gets a response instantly (memory speed). Very high throughput.
  • Reduced DB Load: Multiple writes to the same key can be batched into one DB update.
• Cons:
  • Data Loss Risk: If the cache crashes before syncing to the DB, that data is lost forever.
• Use Case: Analytics counters, Likes/Views, non-critical logging.

4. Read-Through

Often paired with Write-Through. The cache library is responsible for fetching from the DB, not the application.

Flow

1. Read: App asks Cache for Key.
   • Miss: Cache (not App) fetches from DB -> Cache updates self -> Return data.

Analysis

• Pros:
  • Simplifies App Code: Your code just says cache.get(key). It doesn't need "if miss then db" logic everywhere.
• Cons:
  • Vendor Lock-in: Requires a sophisticated cache provider (like Redis Gears or specific plugs) that knows how to talk to your specific DB.

Comparison Summary