TechBlueprints Quick Reference
| Pattern | How It Works | Best For |
|---|---|---|
| Cache-Aside (Lazy Loading) | App checks cache first → miss → fetch from DB → store in cache | Read-heavy, data that may not be accessed |
| Write-Through | App writes to cache → cache writes to DB synchronously | Strong consistency, critical data |
| Write-Behind (Write-Back) | App writes to cache → cache writes to DB asynchronously | Write-heavy, eventual consistency OK |
| Read-Through | App only talks to cache → cache fetches from DB on miss | Simplify app logic, consistent reads |
| Refresh-Ahead | Cache proactively refreshes before TTL expires | Predictable access patterns |
⚠️ Don't update cache on write—invalidate it!
Data expires after X seconds
✓ Simple, automatic
✗ Stale reads possible
Invalidate on write/update events
✓ Fresh data
✗ More complex
Include version in cache key
✓ No explicit invalidation
✗ Key management
| Policy | Evicts | Use Case |
|---|---|---|
| LRU | Least Recently Used | General purpose (most common) |
| LFU | Least Frequently Used | When access frequency matters |
| FIFO | First In, First Out | Simple, predictable |
| Random | Random selection | CPU efficiency over accuracy |
Many requests hit DB when cache expires
Fix: Locking, refresh-ahead, staggered TTL
Queries for non-existent keys hit DB
Fix: Cache null values, bloom filter
Single key overwhelms one cache node
Fix: Replicate hot keys, local cache
| Feature | Redis | Memcached |
|---|---|---|
| Data Structures | Rich (lists, sets, hashes) | Simple key-value |
| Persistence | Yes (RDB, AOF) | No |
| Clustering | Native cluster | Client-side |
| Memory Efficiency | Good | Better (slab allocator) |
| Multi-threading | Single-threaded* | Multi-threaded |
*Redis 6.0+ has I/O threading
"I'd use a [cache-aside/write-through] pattern here with [Redis] because [read-heavy/need data structures]. For invalidation, I'd use [TTL of X minutes/event-based invalidation] to balance freshness with performance."