What is caching and why is it important?
Why Interviewers Ask This
This is a classic screening question for System Design roles. Hiring managers ask it early in interviews to gauge your baseline understanding and determine if you can communicate technical concepts clearly.
Answer
Caching stores copies of frequently accessed data in fast storage (memory) so future requests are served faster, reducing load on the origin (database, API). The fundamental trade-off: freshness (accuracy) vs speed. Cache levels: (1) Client-side: browser cache (CSS, images, JS — reduces network requests); (2) CDN: geographically distributed caches for static content; (3) Application cache: in-process cache (local variable, per-instance — fast but not shared); (4) Distributed cache: Redis, Memcached — shared across multiple app servers; (5) Database cache: query result cache, InnoDB buffer pool. Cache patterns: Cache-aside (Lazy Loading): app checks cache first, on miss reads from DB and populates cache — most common; Write-through: write to cache AND DB simultaneously — no stale data, but every write hits both; Write-back (Write-behind): write to cache only, flush to DB asynchronously — fastest writes, risk of data loss; Read-through: cache sits in front of DB, handles loading automatically. Cache eviction policies: LRU (Least Recently Used), LFU (Least Frequently Used), TTL-based expiry, FIFO. Cache invalidation is notoriously hard — when data changes, stale cached copies must be invalidated or expired. "There are only two hard things in CS: cache invalidation and naming things."
Common Mistake
Don't just define the term — demonstrate that you understand when to use it and when not to. Showing awareness of trade-offs is what separates average from strong System Design candidates.