HLD · Performance

Caching Strategies

Store frequently accessed data closer to the consumer to cut latency and database load.

In simple words: A cache keeps a nearby copy of data that is read often. This makes repeated reads faster, but the copy can become stale when the original data changes. Example: a product page hit 10,000 times per minute can read from Redis after the first request instead of hitting the database every time.

1. Basics: cache hit vs miss

Cache hit: The data is in the cache, so the response is fast.

Cache miss: The data is absent, so the app reads it from the source, such as a database, and usually caches it for later requests.

Example: A product page gets 10,000 views per minute and returns the same JSON. The first request reads the database; later requests can read Redis until the cached value expires.

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

read(key): val = cache.get(key) if val is not missing: return val val = db.get(key) cache.set(key, val, TTL=5min) return val

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

Example (write-around): On profile edit, update the database, delete user:42:profile from Redis, and let the next profile read rebuild the 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	Opaque byte values by key
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 data types and optional persistence; Memcached: simple in-memory values.
Don't cache: Highly personalized, strongly consistent financial balances without careful invalidation.