Caching, hit and miss

Cache hit

Beginner

1. You open a product page.
2. The app first checks its fast notepad: “Do I already know this?”
3. Yes! The answer is there, ready to use.
4. Your page appears quickly, and the database wasn’t bothered at all.

Practitioner

1. The client requests a product.
2. The app looks up the product’s key in the cache.
3. Cache hit: the stored product comes straight back.
4. The app responds without touching the database.

Architect

1. GET /products/42 reaches the app tier.
2. GET product:42 against the cache.
3. Hit, served from memory in well under a millisecond.
4. Response served with zero database load; hit ratio drives both latency and DB sizing.

Cache miss

Beginner

1. You open a page nobody has looked at recently.
2. The app checks its fast notepad first.
3. Nothing there this time.
4. So the app asks the database, which is slower but always has the answer.
5. The database sends back the product.
6. The app writes the answer in its notepad for next time.
7. You get your page. The next person who asks will get it much faster.

Practitioner

1. The client requests a product.
2. The app looks up the key in the cache.
3. Cache miss: the key isn’t stored.
4. The app queries the database.
5. The database returns the row.
6. The app stores the result in the cache with an expiry time.
7. The response goes back; the next request will be a hit.

Architect

1. GET /products/77 reaches the app tier.
2. GET product:77 against the cache.
3. Miss (never cached, expired, or evicted).
4. Fallback query against the primary store.
5. Row returned. This is the expensive path the cache exists to avoid.
6. SET product:77 with a TTL so stale entries eventually age out.
7. Served. Subsequent reads are hits until the TTL expires or the key is invalidated.

Data changes

Beginner

1. Someone changes the product’s price.
2. The app saves the new price in the database first.
3. The database confirms it’s saved.
4. Then the app crosses out the old price in its notepad, so nobody sees a stale answer.
5. Done. The next visitor gets the new price.

Practitioner

1. The client sends an update.
2. The app writes the change to the database.
3. The database acknowledges the write.
4. The app deletes the cached copy so the next read fetches fresh data.
5. The update is confirmed; the next read refills the cache.

Architect

1. PUT /products/42 with a new price.
2. Write committed to the source of truth first.
3. Commit acknowledged.
4. DEL product:42: invalidate rather than update, which avoids racing writers.
5. Write path complete; the next read is a miss that repopulates the key.