⚡ Design Cache Layer — System Design Interview Guide

Easy · Fundamentals

Design and implement a caching layer for a high-traffic web application, covering cache strategies, eviction policies, invalidation, and cache stampede prevention.

Open the interactive Cache Layer design on PrepGrind → Drag load balancers, caches, databases, and queues onto a canvas, run a live traffic simulation to watch latency and bottlenecks under load, and follow the full interview walkthrough below — free, in your browser.

Functional requirements

Cache frequently accessed data to reduce DB load
Support GET, SET, DELETE cache operations
TTL-based expiry for cache entries
Cache miss: fall back to DB and populate cache
Cache invalidation when source data changes

Non-functional requirements & scale

Cache read latency < 1ms (vs DB 10-100ms)
Cache hit ratio > 80% for read-heavy workloads
Cache must not cause data inconsistency with DB
Handle cache failure gracefully (degrade to DB)
Memory-efficient: evict intelligently when full

Capacity estimation

Adding Redis as cache layer in front of PostgreSQL. Application implements cache-aside pattern. Key design: what to cache, TTL selection, and invalidation strategy.

Core entities

CacheEntry — key (string), value (serialized), ttl (seconds), setAt

API design

Internal getUser(userId) — Check Redis → hit: return; miss: query DB → SET Redis → return.
Internal invalidateUser(userId) — DEL Redis key when user record updated.

High-level design

Application → Redis Cache (cache-aside) → PostgreSQL. Write path: always write to DB; invalidate or update cache. Redis sits between application and DB.

Deep dives

🔄 Cache Strategies

Cache-Aside (Lazy): app checks cache → miss → load from DB → populate cache. Write-Through: write to cache and DB simultaneously. Write-Behind (Write-Back): write to cache → async write to DB later (risk of data loss). Read-Through: cache is responsible for fetching from DB on miss. For most use cases: Cache-Aside for reads, Write-Through for writes.

🗑️ Cache Eviction

When cache is full: LRU (Least Recently Used) — evict least recently accessed. Best for temporal locality. LFU (Least Frequently Used) — evict least accessed overall. Best for consistent hot keys. FIFO — evict oldest entry. Simple. TTL: each entry has expiry. Redis supports all: maxmemory-policy = allkeys-lru/lfu. Recommendation: allkeys-lru for general purpose, allkeys-lfu for consistent access patterns.

💥 Cache Stampede

TTL expires on a hot key → 1000 requests all miss simultaneously → 1000 DB queries. Solutions: (1) Mutex locking: first miss acquires lock, others wait. (2) Probabilistic early expiration: randomly extend TTL before it expires to warm cache proactively. (3) Stale-while-revalidate: return stale data while refreshing in background. (4) Background refresh: cron job refreshes hot keys before expiry.

🔧 Cache Invalidation

"There are only two hard things in CS: cache invalidation and naming things." — Phil Karlton. Strategies: (1) TTL-based: accept staleness up to TTL. (2) Event-driven: DB update → publish event → cache invalidation worker deletes key. (3) Write-through: always update cache on DB write. Choose TTL based on how stale data is acceptable. User profile: 5 min stale OK. Bank balance: 0s TTL (no cache).

Scaling considerations

Redis Cluster for horizontal scaling: consistent hashing per shard
Multiple replicas per shard for read scalability
Pipeline multiple Redis commands in one RTT for bulk operations
Monitor cache hit ratio via Redis INFO stats — target > 80%
Sentinel or Redis Cluster for automatic failover

What interviewers expect by level

Junior: Describe cache-aside pattern, basic TTL, why caching reduces DB load.
Mid: Eviction policies, write-through vs cache-aside, cache stampede, TTL selection.
Senior: Cache invalidation strategies, distributed cache (Redis Cluster), monitoring hit ratio, graceful degradation.
Staff: Multi-region cache with replication lag, cache-aware DB query routing, cost model (cache $/GB vs DB $/query).

Practice more system design case studies

PrepGrind runs entirely in your browser, free, no installation required. Loading the interactive playground…