Redis is the dominant infrastructure cache. It stores key-value pairs in memory with optional TTL. It supports complex data structures (sorted sets, lists, hashes) beyond simple string values. Its persistence options (RDB snapshots, AOF logging) allow cache warm-up after restart.
Memcached is a simpler alternative: key-value only, no data structure support, no persistence. It shards data across multiple nodes without the overhead of Redis replication. For pure caching workloads (no persistence needed), Memcached is operationally simpler.
CDN edge caches (Cloudflare, Fastly, Akamai) apply
the same structure to HTTP responses. A URL is the cache key; the HTTP
response body is the cached value;
Cache-Control: max-age=300 is the TTL. Cache-Control
headers are the same interface as programmatic TTL, applied at the HTTP
protocol level.
Database query result caches: many databases (MySQL query cache, PostgreSQL’s pg_query_cache) cache the results of frequently repeated queries. The database is acting as its own cache layer for common read patterns.
Concept: Memoization as Infrastructure Caching (the bridge chapter)
Thread: T5 (Caching/Memoization) ← DP memoization (Book 1, Ch 21) → CDN and cache layer (Book 3, Ch 6–7)
Core Idea: A DP memo table and an infrastructure cache have identical structure: key = subproblem/request, value = result. The difference is mutability: DP subproblems are pure functions; infrastructure caches must handle data change. Cache invalidation — deciding when a cached value is stale — is the entire engineering problem. TTL is the universal escape hatch: tolerate staleness up to a configurable window. Explicit invalidation eliminates staleness but requires every writer to know every cache key.
Tradeoff: AT1 — Consistency vs. Availability (shorter TTL = fresher data, more database load; longer TTL = faster, potentially stale; the cache is always choosing between these)
Failure Mode: FM7 — Thundering Herd (cache expiry under high load causes simultaneous database queries from all waiting clients; protect with jitter, background refresh, or request coalescing)
Signal: When the same expensive computation or query is being repeated with the same inputs — add a cache. When cache hit rate drops below 80% for a read-heavy workload — the key structure or TTL policy is wrong. When a cache sits in front of a database that changes infrequently — a long TTL with explicit invalidation is the right model.
Maps to: Reference Book, Framework 8, Infrastructure Components (Cache Layer)