🗄️ Caching

Cache = Temporary storage for frequently accessed data

First request:
  Client → Server → Database → Response (slow)
  Store in cache

Second request:
  Client → Cache → Response (fast!)
  Skip database entirely

Speed vs Freshness

Cache hit: Data is there, instant response
Cache miss: Data not there, fetch from source

Stale data: Cache has old version
Fresh data: Cache has current version

Balance: Fast enough, fresh enough

Multiple levels of caching:

┌─────────────────────────────────────────────────┐
│ Browser                                          │
│   └─ Browser cache (HTML, CSS, images)          │
├─────────────────────────────────────────────────┤
│ CDN (Edge)                                       │
│   └─ Geographic distribution                    │
├─────────────────────────────────────────────────┤
│ API Gateway                                      │
│   └─ Response caching                           │
├─────────────────────────────────────────────────┤
│ Application                                      │
│   └─ In-memory cache (Redis, Memcached)         │
├─────────────────────────────────────────────────┤
│ Database                                         │
│   └─ Query cache, buffer pool                   │
└─────────────────────────────────────────────────┘

1. Check cache
2. Cache miss? Fetch from database
3. Store in cache
4. Return response

App controls caching explicitly.

Write to cache AND database together.

Data is kept in sync (when all writes go through this path).
Slower writes (two writes).

Write to cache immediately.
Asynchronously sync to database.

Fast writes.
Risk: data loss if cache fails before sync.

Cache handles loading from database.
App talks to the cache, and the cache fetches from the database on misses.

Cache as the single point of access.

"A famous joke: there are two hard things in computer science:
cache invalidation and naming things."

When underlying data changes,
cache needs to know!

Time-based (TTL):
  Entry expires after a set time
  Simple but may serve stale data

Event-based:
  Database updated → Invalidate cache
  Immediate but more complex

Version-based:
  Cache key includes version number
  New version = new key = fresh data

Short TTL (very short):
  Fresh data
  More cache misses
  More database load

Long TTL (long):
  Stale data risk
  Fewer cache misses
  Less database load

Balance based on your needs.

Key design matters!

Simple: "user:123"
With params: "user:123:profile:v2"
Hash: md5(request_url + params)

Good keys:
✓ Unique per data item
✓ Consistent generation
✓ Efficient lookup

Hit ratio = cache hits / total requests

90% hit ratio:
  90 requests served from cache
  10 requests go to database

Higher is better!
Monitor and optimize.

✓ Longer TTL (if freshness allows)
✓ Preload popular items (cache warming)
✓ Better key design
✓ Larger cache size

Preload cache before traffic hits:

App starts → Load popular items into cache

Avoids cold start cache misses.

Multiple app servers share one cache:

App 1 ─┐
App 2 ─┼──→ Redis Cluster ──→ Database
App 3 ─┘

All servers see same cached data.

Two levels:

Request → Local cache (very fast)
        ↓ miss
        → Remote cache (fast)
        ↓ miss
        → Database (slow)

Local cache for hot data.
Remote cache for shared data.

Cache what's:
✓ Expensive to compute
✓ Frequently accessed
✓ Stable enough

Don't cache:
✗ Rarely accessed data
✗ Constantly changing data
✗ User-specific infrequently accessed data

User changes profile.
Cache shows old profile.
User confused!

Plan for invalidation from the start.

Cache keeps growing forever.
Memory exhausted!

Set max size + eviction policy (LRU, LFU).

TTL expires.
1000 requests simultaneously:
  All miss cache.
  All hit database.
  Database overwhelmed!

Solution: Locking, early expiration, staggered TTL.