Think about a popular Flipkart product page during a sale — the same iPhone listing, viewed by a million people in an hour, and its price and description haven't changed since yesterday. Fetching that SAME unchanged data from the database, a million separate times, is pure waste. Caching is the single highest-leverage idea in this entire course precisely because so much of real traffic looks exactly like this: the same answer, asked for again and again.
What a cache actually is
A cache is a smaller, much faster store sitting between your application and a slower system of record (usually a disk-backed database) — typically held entirely in RAM. Reading from RAM is routinely a hundred to a thousand times faster than a disk-backed database round trip, so if the same data is asked for repeatedly, answering from the cache instead of the database cuts both latency and database load dramatically.
The tool this lesson keeps pointing at
RedisThe cache-aside pattern
The most common caching pattern works like this: on a read, first check the cache. If the data is there (a cache hit), return it immediately — the database is never touched. If it's not there (a cache miss), read from the database, return the result to the caller, AND also write it into the cache so the next request for the same key is a hit.
Write-through vs write-back caching
Cache-aside describes the READ path — but what happens on a WRITE? Write-through writes to the cache AND the database before acknowledging the write as done — slower per write, but the cache and database can never disagree. Write-back writes to the cache and immediately acknowledges, flushing to the database later, asynchronously — faster writes, but if the cache crashes before that flush happens, that write is gone forever. This is a genuine durability-vs-speed trade-off, not a free upgrade either way.
Eviction: TTL, LRU, LFU
A cache is much smaller than the database it sits in front of, so it must decide what to remove when it fills up. A TTL (time-to-live) simply expires an entry after a fixed duration, regardless of how often it's used. An LRU (least recently used) policy evicts whatever hasn't been accessed in the longest time, keeping genuinely popular items around naturally. An LFU (least frequently used) policy tracks actual access counts instead of recency — useful when "popular over time" matters more than "popular recently."
The hardest problem: invalidation
There is a well-known joke in engineering that there are only two hard problems in computer science: cache invalidation, and naming things. The core issue: once data changes in the database, the cached copy is now WRONG until it's updated or removed — and deciding exactly when and how to do that, across every place that data could change, is genuinely tricky to get perfectly right. Most systems accept a short window of staleness (via a TTL) rather than trying to invalidate perfectly on every possible write path.
Hot keys and cache stampedes
A hot key is one cache entry — say, a viral product's price — being read far more often than any other, which can overload the single cache node or shard holding it. A cache stampede (or dog-piling) happens when a hot key expires and a flood of simultaneous requests all get a cache miss at once, each independently hammering the database at the same instant — sometimes enough to take the database down. Common fixes: a lock so only one request rebuilds the cache while others briefly wait, or serving slightly stale data during a background refresh.
Common mistakes
- Adding a cache without ever answering "what happens when it's wrong?"
- Choosing write-back for data where losing a recent write would be unacceptable (e.g. financial records).
- Caching data that changes on every read anyway, gaining nothing.
- Ignoring the cache-stampede risk for genuinely hot, expiring keys.
Quick recap
| Concept | One-liner |
|---|---|
| Cache-aside | Check cache first; on a miss, read DB and populate the cache. |
| Write-through | Safer, slower — cache and DB updated together. |
| Write-back | Faster, riskier — cache updated now, DB updated later. |
| Eviction | TTL (time-based), LRU (recency), LFU (frequency). |
| Cache stampede | Many simultaneous misses on one expiring hot key hammer the DB at once. |
Practice Zone
Five MCQs, then two applied questions.
In the cache-aside pattern, what happens on a cache MISS?
Asked in
What does an LRU (Least Recently Used) cache eviction policy do when the cache is full?
Asked in
A very popular product's cache entry expires. In the next 5 milliseconds, 10,000 requests for that same product arrive. What problem is this, and what's one common fix?
Asked in
What is the main trade-off of write-BACK caching compared to write-THROUGH?
Asked in
Why is Redis (an in-memory store) commonly used as a cache instead of just querying the database every time?
Asked in
An e-commerce product page is read 50,000 times/minute but the price/stock changes at most once every few minutes. Design a caching approach: what do you cache, for how long, and what do you do when the price changes?
Asked in
Every day at midnight, a 'daily deal' price cache key expires, and every day your database gets briefly hammered by a spike of simultaneous requests. Propose a fix.
Asked in
FAQ
Is Redis the only caching option?
It's the most common in interviews and in practice, alongside Memcached — Redis additionally supports richer data structures and persistence, which Memcached deliberately keeps simpler and purely in-memory.
Should I cache everything?
No — caching helps most for read-heavy, rarely-changing, repeatedly-requested data. Highly personalized or constantly-changing data gains little and adds invalidation complexity for no real benefit.
What's the difference between a cache and a CDN?
A CDN is essentially a geographically distributed cache specifically for static content, placed close to users worldwide — covered in its own lesson later in this course.