HLD · Performance
Caching Strategies
Store frequently accessed data closer to the consumer to cut latency and database load.
1. Basics: cache hit vs miss
Cache hit: Data found in cache → fast response (e.g., 1ms from Redis).
Cache miss: Data not in cache → fetch from source (DB, 50ms), store in cache, return.
Example: Product page for iPhone case — 10k views/min, same JSON. First request hits DB; next 9,999 hit Redis.
2. Where to cache (layers)
- Client / browser: HTTP cache headers (
Cache-Control) - CDN edge: Static assets, some API responses at PoP near user
- Application cache: In-process (Caffeine, Guava) — ultra fast, not shared across instances
- Distributed cache: Redis/Memcached — shared across all app servers
- Database buffer pool: DB's own page cache (you configure indirectly via query patterns)
3. Cache-aside (lazy loading) — most common
App owns cache logic. On write: update DB, then invalidate or update cache.
Pros: Only hot data cached; cache failure doesn't break reads (falls back to DB).
Cons: First request always slow; stampede risk on expiry (see below).
4. Write-through vs write-back
| Pattern | Write path | Use when |
|---|---|---|
| Write-through | Write cache + DB together | Strong consistency between cache and DB |
| Write-back | Write cache first; DB updated async | Write-heavy, can tolerate brief loss on crash |
| Write-around | Write DB only; invalidate cache | Infrequent writes, avoid polluting cache |
5. Eviction policies
- TTL (time-to-live): Expire after N seconds — simplest for interviews.
- LRU: Evict least recently used when memory full.
- LFU: Evict least frequently used — better for skewed access.
6. Cache problems (must know)
Cache stampede / thundering herd
Popular key expires; 1000 requests simultaneously miss and hammer DB.
Fixes: Probabilistic early expiry, request coalescing (single flight), mutex per key, stale-while-revalidate.
Stale data
User sees old price after update. Fix: Invalidate on write; short TTL for volatile data; version keys.
Hot key
One key (celebrity profile) overloads single Redis shard. Fix: Replicate hot key across shards, local in-process copy, read replicas.
7. Redis vs Memcached (interview)
| Redis | Memcached | |
|---|---|---|
| Data structures | Strings, lists, sets, sorted sets, hashes | Strings only |
| Persistence | Optional (RDB/AOF) | None (pure cache) |
| Best for | Sessions, leaderboards, pub/sub, complex caching | Simple key-value blob cache |
8. Example: caching user profile
Key: user:12345:profile, TTL 10 min. On profile update API: DEL user:12345:profile. On login burst: warm cache from DB once.
Quick revision
- Cache-aside: Read cache → miss → DB → populate. Invalidate on write.
- Layers: Browser → CDN → app → Redis → DB.
- Eviction: TTL + LRU when memory bound.
- Pitfalls: Stampede, stale data, hot keys.
- Redis: Rich types + persistence; Memcached: simple & fast.
- Don't cache: Highly personalized, strongly consistent financial balances without careful invalidation.