Caching Fundamentals

Build the mental model

Caching exists because some work is expensive to repeat: a complex database query, a computation, a rendered page — and if the same result is needed again soon after, redoing that work from scratch wastes time and load on the underlying system. A cache stores that result somewhere fast (usually in memory) so the next request for the same thing can be answered instantly instead. The most common pattern is cache-aside: the application checks the cache first, and on a cache hit returns the stored value immediately; on a cache miss, it falls back to the real source (the database), fetches the fresh value, populates the cache with it, and then returns it — so only the first request pays the full cost. Write-through is the alternative for keeping data fresh: writes go to the cache and the source together, so the cache is never behind. The fundamental risk in both is staleness: if the underlying data changes without the cache being told, the cache keeps confidently serving an outdated value, and unlike a slow response, a stale response looks correct while being wrong — which is why cache invalidation has to be handled deliberately, not assumed.

Connect it to a real scenario

The Tutorial Platform already benefits from caching in obvious places: a lesson's content rarely changes, so instead of querying the database on every single page view, the platform can cache the rendered lesson using cache-aside — check cache, and only hit the database on a miss. But if an author edits that lesson, a stale cache would keep serving learners the old wording indefinitely, so the platform needs a TTL or explicit invalidation on publish so readers eventually (or immediately) see the update. This same trade-off — freshness versus repeated expensive work — comes up again for search-suggest results, trending-lesson rankings, and any other data the platform doesn't want to recompute per request.

Caching avoids repeating expensive work (a DB query, a computation) by storing the result somewhere fast for reuse.
Cache-aside checks the cache first and only falls back to the source on a miss, populating the cache afterward; write-through updates cache and source together on every write.
A cache can go stale and confidently serve wrong data if invalidation (TTL or explicit) isn't handled deliberately — a stale response looks correct while being wrong.

Try the working example

text

Request for lesson "intro-to-arrays"
            |
            v
     +--------------+
     | Check cache  |
     +--------------+
        |         |
      HIT        MISS
        |         |
        v         v
  +-----------+  +------------------+
  | Return    |  | Query database    |
  | cached    |  +------------------+
  | value     |         |
  | (fast)    |         v
  +-----------+  +------------------+
                 | Populate cache    |
                 +------------------+
                         |
                         v
                 +------------------+
                 | Return value      |
                 | (slower, once)    |
                 +------------------+

You should see

The diagram shows the cache-aside flow, where a hit returns instantly but a miss must query the database, populate the cache, and only then return.

5-minute try-it

Pick a feature (e.g. a user profile page) and decide whether cache-aside or write-through fits better, and explain why.

One important caution

Caching data with no TTL and no invalidation plan, so once the underlying source changes, the cache serves outdated results indefinitely with no mechanism to ever correct itself.

Setting a TTL so short that most requests miss the cache anyway, defeating the purpose of caching while still paying the added complexity and memory cost of running one.

Wikipedia — Cache (computing) — System Design