Cache Strategies

Without cache:
  All 100,000 reads/sec hit the database
  DB latency: 50ms average
  DB is overloaded, response times spike to 500ms+

With cache (90% hit rate):
  90,000 reads/sec served from cache (1ms)
  10,000 reads/sec hit the database (50ms)
  Average latency: 0.9 × 1ms + 0.1 × 50ms = 5.9ms

  DB load reduced by 90%
  Average latency reduced by 88%
  DB has headroom for writes and complex queries

function getUser(userId) {
  // Step 1: Check cache
  const cached = cache.get("user:" + userId);
  if (cached) return cached;  // Cache HIT → return immediately

  // Step 2: Cache MISS → fetch from DB
  const user = db.query("SELECT * FROM users WHERE id = ?", userId);

  // Step 3: Populate cache (TTL = 5 minutes)
  cache.set("user:" + userId, user, { ttl: 300 });

  // Step 4: Return
  return user;
}

// On write: invalidate the cache
function updateUser(userId, data) {
  db.query("UPDATE users SET ... WHERE id = ?", userId);
  cache.delete("user:" + userId);  // Force next read to fetch fresh data
}

Cache-Aside (application manages):
  App → check cache → miss → App queries DB → App writes to cache

Read-Through (cache manages):
  App → check cache → miss → Cache queries DB → Cache stores result
  App only ever talks to the cache. The cache handles DB fetching.

From the application's perspective:
  const user = cache.get("user:42");
  // If miss, the cache library fetches from DB automatically
  // App doesn't know or care whether it was a hit or miss

App: "Update user #42 name to Alicia"
  │
  ├──→ Cache: SET user:42 = {name: "Alicia"}  ✅
  │
  └──→ DB: UPDATE users SET name = 'Alicia' WHERE id = 42  ✅
  │
  └──→ App: "Write confirmed" (both succeeded)

Result:
  Cache and DB are always in sync
  Any subsequent read from cache returns fresh data
  No stale data window

Trade-off:
  Write latency = max(cache write, DB write)
  Typically 50-100ms (DB is the bottleneck)
  Every write is slower, but reads are always consistent

App: "Update user #42 name to Alicia"
  │
  ├──→ Cache: SET user:42 = {name: "Alicia"}  ✅
  │
  └──→ App: "Write confirmed" (instant, ~1ms)

  ... later (async, batched) ...

  Cache ──→ DB: UPDATE users SET name = 'Alicia' WHERE id = 42

Timeline:
  T=0ms:   App writes to cache → confirmed
  T=0-1ms: App continues processing (no DB wait)
  T=100ms: Cache flushes batch to DB (background)

Comparison:
  Write-through: write latency = ~50ms (wait for DB)
  Write-behind:  write latency = ~1ms  (cache only)
  → 50x faster writes

Product Page Request Flow:

  Client → App Server → Redis Cache
                          │
                          ├── product:42:details  (cache-aside, TTL 10min)
                          ├── product:42:price    (write-through, always fresh)
                          ├── product:42:reviews  (cache-aside, TTL 30min)
                          ├── product:42:stock    (cache-aside, TTL 10sec)
                          └── product:42:views    (write-behind, flush every 5s)

Cache hit (95% of requests): ~2ms total
Cache miss: ~20-50ms (one DB query, then cached)

DB load: reduced from 50,000 QPS to ~2,500 QPS (95% absorbed by cache)
Result: fast page loads, healthy database, happy users