System Design - Caching
Serve hot data from memory and pick the write strategy that matches your risk tolerance.
What is a cache?
A fast in-memory store that holds copies of hot data so the slower database is hit less often.
Where you will see it
Real systems that use this exact idea. Tap a card to open it.
Common traps
The mistakes interviewers watch for. Guess the fix, then reveal it.
FixEvery cached value is a staleness liability and memory cost. Cache the hot 20% that serves 80% of traffic - measure first.
FixUniform TTLs align expiries into stampedes. Jitter TTLs and tier them by data volatility.
FixAn unbounded cache OOMs its host. Set maxmemory with an eviction policy (allkeys-lru or volatile-lru) from day one.
Interview prep
Questions you could be asked, with the depth an interviewer wants to hear.
Cache-aside has the app check the cache and fill it on a miss. Write-through writes cache and database together. Write-behind writes the cache and flushes to the database asynchronously.
staleness vs latency
Real worldCache-aside is the most common pattern because the app stays in control; write-behind suits write bursts.
DeeperEach trades staleness risk against write latency - know which you are accepting.