Cache-Aside Example: A Product Page

Miss, fetch, store, then hit: the steps every cached read takes.

Cache-aside is the most common way to use a cache: the application asks the cache first, reads the database on a miss, stores what it read in the cache, and returns it. The cache sits aside from the database and knows nothing about it; the application does all the work. Two reads of one product show every step.

The setting. A shop's product page reads product 42 from a Redis cache in front of its database. Cached entries expire after 300 seconds, set with Redis's EX option. The cache starts empty.

Two reads of product 42, run with python:3.12-slim (Python 3.12.13)

InputRead product 42 twice, starting from an empty cache

start
1. empty
Cache empty, database queries: 0
read 1: GET product:42
1. empty
Miss: the cache has no entry, queries: 0
read 1: SELECT * FROM products WHERE id = 42
1. empty
The database answers, queries: 1
read 1: SET product:42 EX 300
1. product:42stored
The value is stored for 300 seconds, queries: 1
read 2: GET product:42
1. product:42hit
Hit: returned from the cache, queries: 1

ResultTwo reads, one database query. The cached value was {"id": 42, "name": "Desk lamp", "price": 39.00}.

Predict before the second read. With the entry stored, how many queries will the database have run after read 2? The trace says one: the second read never reaches it. Every further read in the next five minutes is the same.

What to notice. The store step is what makes the next read a hit. Code that returns the value before storing it, or forgets to store it, misses on every read and gains nothing from the cache. The database is never written by this pattern; it is only read on a miss.

So every cached read is the same four steps, look, fetch on a miss, store, return, and the store is the step that pays for all the hits after it.

← → move through sections and cards