Designing Caching Architecture

1. Designing Cache Hierarchies

TierLatencyExamples
Browser0msCache-Control, ServiceWorker
CDN edge10–50msCloudflare, CloudFront
Reverse proxy1–5msVarnish, NGINX
App in-processµsCaffeine, Guava, lru-cache
Distributed~1msRedis, Memcached
DB cache~msBuffer pool, materialized views

2. Designing Cache-Aside Pattern

Cache-Aside (Lazy Loading)

  1. App reads cache; on miss, reads DB
  2. App writes value to cache with TTL
  3. On write, app updates DB then invalidates/updates cache
ProCon
Resilient (cache failure ≠ outage)Stale data possible; thundering herd

3. Designing Write-Through Cache

AspectDetail
FlowApp writes cache → cache writes DB synchronously
ConsistencyStrong cache+DB
LatencyHigher write latency
UseRead-heavy with consistent cache

4. Designing Write-Behind Cache

AspectDetail
FlowApp writes cache; cache flushes to DB async
ProLow write latency, batching
ConRisk of data loss on cache crash; harder consistency
UseCounters, analytics, bursty writes

5. Designing Read-Through Cache

AspectDetail
FlowApp always asks cache; cache loads from DB on miss
ProApp code simpler
ConRequires cache library / provider integration
ExamplesHibernate 2nd-level, AWS DAX

6. Understanding Cache Eviction Policies

PolicyBehaviorBest For
LRUEvict least recently usedGeneral workloads
LFUEvict least frequently usedSkewed access
FIFOEvict oldest insertStreams, queues
TTL-basedTime-bound entriesTime-sensitive data
ARC / W-TinyLFUAdaptive (Caffeine)High hit ratio
RandomCheap; OK at high hit rateMemory-constrained

7. Designing Cache Warming Strategies

StrategyWhen
Pre-load on deployPredictable hot keys
Replay logsWarm new node from access log
Background refresherRefresh entries before expiry
Shadow trafficMirror prod requests to new node

8. Designing Cache Invalidation Strategies

StrategyDescription
TTLTime-based; simple but stale window
Explicit invalidate on writeStrong; risk of race
Write-throughUpdate cache atomically
Tag-basedInvalidate group via tag
Versioned keysBump version → effectively new key
CDC-drivenDB change events update cache
Warning: "There are only two hard things in computer science: cache invalidation and naming things." Pick the simplest correct strategy for your consistency need.

9. Implementing Distributed Caching

SystemStrength
Redis ClusterData structures, pub/sub, persistence
MemcachedSimple K/V, multi-threaded, very fast
Hazelcast / IgniteIn-memory data grid, compute
DragonflyDB / KeyDBRedis-compatible, multi-threaded
ShardingConsistent hash across nodes

10. Designing Cache Stampede Solutions

TechniqueDescription
Request coalescingSingleflight: 1 fetch per key, others wait
Lock + recomputeDistributed lock during recompute
Probabilistic early expireRefresh before TTL with probability
Stale-while-revalidateServe stale; refresh in background
Jittered TTLsAvoid synchronized expiration

11. Designing Cache Consistency Strategies

StrategyOrder of OpsRisk
Update DB → invalidate cacheWrite DB, DEL cacheStale if reader sees old before DEL
Update DB → update cacheAtomic with txn outboxRace in concurrent writes
Cache-aside double-deleteDEL, write DB, DEL again after delayReduces race window
CDC streamDebezium → cache updaterMost consistent

12. Designing Multi-Level Cache Architecture

   Client ─▶ L1 (in-process Caffeine) ─▶ L2 (Redis) ─▶ DB
              hit µs               hit ~1ms
   Invalidation: DB write → CDC → Redis update → pub/sub → L1 evict
      
LevelSizeHit Latency
L1 (local)MB-GBµs
L2 (distributed)GB-TB~1ms
L3 (CDN/edge)TB+10–50ms