System Design · Architecture under constraints
What caching layers and patterns should you know?
Short answer
Caches can sit in the browser, CDN, reverse proxy, application or database. Common patterns are cache-aside, write-through and write-behind; the hard parts are invalidation, TTLs and stampedes.
A cache stores a copy of data closer to the reader or cheaper to fetch. It improves latency and reduces load on the origin, but it introduces staleness and a second place where data can be wrong. The design question is not whether to cache but what staleness the product can tolerate.
Layers, from closest to farthest
- Browser cache: HTTP headers and local storage, with no server round trip on a hit
- CDN edge: static assets and cacheable API responses, close to users
- Reverse proxy or gateway: shared responses across application instances
- Application cache: Redis or Memcached for computed objects and hot keys
- Database cache: buffer pool and query cache, usually managed by the engine
Patterns
- Cache-aside: the application reads the cache, loads from the source on a miss, then populates the cache
- Read-through: the cache library loads on a miss, centralizing the logic
- Write-through: writes go to the cache and the source synchronously, keeping them closer in time
- Write-behind: writes land in the cache and flush later, which is faster but risks data loss
- Refresh-ahead: refresh popular entries before they expire to avoid a miss
Invalidation is the hard part. TTL is simple but bounds staleness rather than eliminating it. Explicit invalidation is precise but easy to miss when multiple writers exist. Versioned keys avoid stale overwrites because a new version never aliases an old one. For hot keys, add jitter to TTLs and use a single-flight lock so a miss does not send thousands of requests to the origin.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you prevent a cache stampede after expiry?
- 2When is write-behind acceptable?
- 3How do you invalidate a CDN cache safely?
- 4What would you monitor to know the cache is helping?
Say it in the interview
Caching happens at several layers, from the browser down to the database, and the pattern determines the consistency risk. I usually start with cache-aside plus a TTL, then add explicit invalidation only where the product needs it. I protect hot keys with jitter and single-flight loading so an expiry does not stampede the origin. And I always treat the cache as disposable, because the system must survive a full flush.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live System Design mock interview and get scored feedback on depth, clarity and confidence.