Inkwell Shop, where writers sell prints of their work. A few bestsellers get most of the page views, and almost every request is a read.

What it does

• Read: a shopper opens a product page.
• Write: the store updates a product's price.

Workload

A steady 8 000 rps, 98% reads / 2% writes, for 20 seconds, over 20 000 products. Popularity is skewed (Zipfian): the top few hundred products get most of the views.

What a cache does

A cache keeps recently read data in memory. Answering from memory takes a fraction of a millisecond, a trip to the database takes several. Put it between the app server and the database (app server → cache → database): hits are answered by the cache, misses go on to the database and the answer is kept for next time.

A bigger cache tier holds more products, so more requests are hits.

The hard part is writes. When a price changes, the cached copy is now wrong. The cache's Write strategy decides what happens:

• invalidate: drop the cached copy, so the next read fetches the new price.
• write_through: replace the cached copy with the new value.
• bypass: leave the cached copy alone. It stays wrong until it's evicted.

Tiers

• Easy: stays up. 8 000 rps is more than the starter app tier and database can take. Use what you learned in Survive the Launch.
• Medium: fast pages. Median under 18 ms. A bigger database alone won't get there: every trip to it costs more than a cache hit.
• Hard: fresh prices. Still fast, and almost no shopper sees a price more than 100 ms old.

Hints

• The cache's Metrics tab shows its hit rate.