Course outline · 0% complete

0/29 lessons0%

Course overview →

Cache-aside, step by step

lesson 3-2 · ~10 min · 8/29

The cache-aside pattern

Lesson 3-1 said caches hold copies, but not who puts the copies there or when. That decision is a caching pattern, and choosing one is the first thing you do when adding a cache to real code. Cache-aside (also called lazy loading) is the most common pattern in production backends, and you can write it in six lines. On every read:

  1. Look in the cache first
  2. Hit: return the cached value, done
  3. Miss: read from the database, store a copy in the cache, return it

The first request for any key is slow (a miss), and every request after that is fast, until the entry is removed. The cache fills itself with exactly the data people actually ask for, which is why it is called lazy.

In the simulation below, a Python dict named cache plays the role of Redis and a dict named db plays the database. The pattern is identical in production, just with network calls instead of dict lookups.

Code exercise · python

Run the cache-aside simulation. Watch the first read of each user miss, and repeats hit.

Code exercise · python

Your turn: measure the hit rate. Loop over the request list applying cache-aside (no printing inside the loop), counting hits and misses. Then print the three summary lines shown in the expected output. The hit rate is hits divided by total requests, as a whole percent.

Quiz

With cache-aside, what happens the very first time any user requests a freshly deployed page?