Module 3 8 lessons 109 min

Caching

Dinner traffic grows, and most requests ask for the same few menus. The database runs the same query again and again. Put a cache in front of it - and see what goes wrong when the cache serves stale data.

In this module

7 Read · 1 Lab

  1. 3.1Why cache, and whatHits, misses and TTL. Cache only when you must, and pick data by how often it changes.Read12 min
  2. 3.2Where the cache livesIn-process or a cache server like Redis - and why one server needs nothing more than the first.Read10 min
  3. 3.3Reading and writing with a cacheCache-aside, read-through, write-through and refresh-ahead - and why the database is written first.Read15 min
  4. 3.4Cache invalidationTTLs and invalidating on write. Cache data to show it, but check the database before you act on it.Read12 min
  5. 3.5When the cache is fullLRU, LFU and the rest. Watch the hit rate and the eviction rate to see if your cache is working.Read12 min
  6. 3.6When caching makes things worseKeys that expire together, a hot key that expires, lookups for data that doesn't exist - and the fix for each.Read15 min
  7. 3.7Proof: the menu page with a cacheThe same load test with and without the cache: requests per second, p99, database CPU and hit rate. Then every key expires at once.Read8 min
  8. 3.8Lab: What can the clinic cache?Cache the doctor list. Never the free slots - a stale slot is a double booking.Lab25 min
Start with 3.1 · Why cache, and what
Then · Module 4When one server isn't enough