Common patterns

• Cache-aside: application checks cache, loads from the database on a miss, then populates the cache.
• Read-through: cache abstraction loads missing values from the backing store.
• Write-through: writes update cache and backing store in a coordinated path.
• Write-behind: cache accepts writes and persists them asynchronously; this introduces durability and recovery risks.
• CDN caching: serves eligible responses near users.

Cache decisions

• What is the cache key?
• How long may data remain stale?
• What triggers invalidation?
• What happens on cache failure?
• Can a hot key overload one node?
• Can many simultaneous misses overload the database?

Common problems

• Cache stampede: many requests regenerate the same missing item. Use request coalescing, jittered TTLs, or controlled refresh.
• Hot key: one key receives disproportionate traffic. Consider replication, local caching, or key splitting where semantics allow.
• Stale data: use explicit freshness requirements and invalidation strategies.
• Cache penetration: repeated requests for nonexistent data can bypass the cache; carefully cache negative results when appropriate.

Cache hit ratio = cache hits / total cache lookups.

A high hit ratio is useful but does not guarantee good performance; a few expensive misses or oversized values can still dominate latency. Never treat a cache as the sole durable copy of important data unless its durability guarantees explicitly support that design.