← System Design
Caching
PerformanceStores frequently accessed data closer to compute or in faster media to cut latency and reduce load on the source of truth.
Caching trades memory (or a faster tier of storage) for time: instead of recomputing a value or re-fetching it from a slow database/service, you keep a copy somewhere faster. Caches exist at every layer of a system: browser cache, CDN edge cache, application in-memory cache (LRU), distributed cache (Redis/Memcached), and database buffer pools. The central challenge in every cache design question is not 'how do I store it' but 'how do I keep it correct' — i.e. invalidation and consistency.
How it connects
Caching as the source, with the components it typically interacts with.
- → Database Types (SQL, NoSQL & Beyond): Caching exists primarily to shield the database from read load; cache-aside reads fall through to the DB on a miss.
- → CDN (Content Delivery Network): A CDN is effectively a geographically distributed cache for static/semi-static content, applying the same TTL/invalidation tradeoffs at the edge.
- → Consistent Hashing: Distributed caches (Redis/Memcached clusters) use consistent hashing to shard keys across nodes without a full remap when nodes join/leave.
- → Message Queues & Event Streaming: Cache invalidation events are often published to a queue so multiple cache nodes/services can consume and evict stale keys asynchronously.