Priya Nair·
Six cache layers with the stampede lock spelled out - the bit everyone skips was right there
Designs a comprehensive caching architecture spanning browser, CDN, application, and database layers with cache invalidation and consistency patterns.
Multi-Layer Caching Strategy
Act as a Performance Engineer and Caching Specialist who optimized systems handling billions of requests. Design a multi-layer caching strategy.
**Application Type**: {{application_type}} (e.g., e-commerce product catalog, social media feed, news website, API platform)
**Data Access Patterns**: {{data_access_patterns}} (read-heavy ratios, hot data identification, temporal locality)
**Data Freshness Requirements**: {{data_freshness_requirements}} (acceptable staleness per data type, real-time needs)
**Current Latency Issues**: {{current_latency_issues}} (which endpoints are slow, P95/P99 measurements, bottlenecks)
Design the complete caching stack:
1. **L1: Browser Cache** - Cache-Control headers strategy, ETag generation, immutable assets, service worker caching
2. **L2: CDN Cache** - CloudFront/Cloudflare/Fastly cache behaviors, edge caching dynamic content, cache key design, purge API
3. **L3: Load Balancer Cache** - Nginx caching layer, microcaching for semi-dynamic content, cache lock for thundering herd
4. **L4: Application Cache** - In-process caching (LRU/LFU), cache size calculation, memory management, off-heap caching
5. **L5: Distributed Cache** - Redis/Valkey cluster design, eviction policies (allkeys-lru/volatile-ttl), hash slot distribution
6. **L6: Database Cache** - Query cache configuration, buffer pool sizing, prepared statement caching, connection caching
7. **Cache-Aside vs Read-Through vs Write-Through** - Pattern selection per data type with sequence diagrams
8. **Cache Invalidation Strategy** - TTL-based, event-driven invalidation, write-through invalidation, pattern-based purging
9. **Cache Warming** - Pre-population strategy, warm on deploy, background refresh before TTL expiry
10. **Thundering Herd Prevention** - Cache locks, probabilistic early expiration, request coalescing (singleflight)
11. **Cache Consistency** - Strong vs eventual consistency, cache-database sync strategies, stale data detection
12. **Serialization** - Protocol Buffers, MessagePack, JSON comparison with compression (Snappy/LZ4/zstd)
13. **Monitoring** - Cache hit ratio targets per layer, miss rate alerts, eviction rate, memory usage, latency impact
Include specific Redis configuration and cache header examples for each layer.
Ergebnisse
Multi-layer cache for a **product catalog** (read-heavy ~95%, hot SKUs concentrated, 5-min staleness fine on listings). The job is to make the origin almost never get hit.
| Layer | Tech | TTL | Key strategy |
|-------|------|-----|-------------|
| L1 browser | `Cache-Control` + ETag | 60s | immutable hashed assets |
| L2 CDN | CloudFront | 5m | normalized path + currency header |
| L3 app | in-proc LRU | 30s | hot SKUs, ~10k entries |
| L4 distributed | Redis | 5m | `cat:product:{sku}` |
**Headers per layer:**
```
# Listings — short, shared
Cache-Control: public, max-age=300, stale-while-revalidate=60
# Hashed JS/CSS — forever
Cache-Control: public, max-age=31536000, immutable
```
**Pattern:** cache-aside everywhere. **Stampede protection** is the part people skip — on an L4 miss, a Redis `SET key val PX ttl NX` lock means exactly one request rebuilds while others briefly serve stale:
```
val = redis.get(key)
if miss:
if redis.set(lockKey, 1, "PX", 5000, "NX"): # I won the lock
val = loadFromDb(); redis.set(key, val, "PX", ttl)
else:
val = staleVal || loadFromDb() # others don't dogpile
```
**Invalidation:** write-through busts the SKU key plus a CDN purge-by-tag on price changes. **Redis config:** `maxmemory-policy allkeys-lru`, payloads serialized with MessagePack + LZ4. Target hit ratios: CDN > 90%, Redis > 80%; alert if Redis eviction rate climbs (cache too small).
Modell: Claude Opus 4
9 Likes2 SavesScore: 5
1 Kommentar
Ahmed Hassan·
The observability hooks are a thoughtful touch.