Art of Codeartofcode
Lesson 6 of 16

12. Caching: The Basics

1
The picture to keep in your head
2
12.1 What is a cache, and what are a hit, a miss and the hit rate?
3
12.2 Why is a cache faster than the database?
4
12.3 Where does a cache physically live?
5
12.4 On a miss, who fetches the data?
6
12.5 When the data changes, what gets written where?
7
12.6 What happens when the real data changes, and why add jitter?
8
12.7 What happens when the cache is full?
9
12.8 How do you invalidate safely, and what's the race everyone hits?
10
12.9 When should you cache, what should you never cache, and how do you name keys?
11
Memory card and where the analogy breaks
12
Practice: five levels
13
Interview questions
14
Solutions
15
Sources
16
Code lab
12. Caching: The Basics

12.5 When the data changes, what gets written where?

3 min read+10 XP

In the kitchen: The milk's price changes. You could update both your price list and the fridge label at once; update the fridge label now and tell the shop later; or tell only the shop and throw the old carton out.

In the system: These are the three write strategies.

write-through, write-back and write-around compared.

Figure: three ways to write. Never use write-back for money.

12.5.1 Write-through

In the kitchen: Change the shop's price and the fridge label in the same breath.

In the system: Every write goes to the database and the cache together. The cache is always fresh, and the next read is a hit. Writes are a little slower (two writes), and you may fill the cache with data nobody reads. Good for data that's read right after it's written, like a user's profile after they edit it.

12.5.2 Write-back (write-behind)

In the kitchen: Scribble the new price on the fridge label now, and update the shop's records at the end of the week.

In the system: Writes go only to the cache, which writes them to the database later, often in batches. Fastest writes, and many updates to one key collapse into one database write. But if the cache crashes before flushing, those writes are lost (in the chapter's code, one unflushed price change disappears on a crash), and the database is briefly behind. Good for things where a small loss is acceptable and the write rate is huge: view counters, likes, metrics. Never for money or orders.

12.5.3 Write-around

In the kitchen: Tell only the shop the new price, and throw out the old carton. The next time you need milk, you'll buy the fresh one.

In the system: Writes go only to the database, and any cached copy is deleted (or simply left to expire). The next read misses and loads the fresh value through cache-aside. Simple and safe; the cache holds only data that's actually read. It's the most common pairing with cache-aside, and the subject of the race in 12.8.

Memory code: "Through: both now. Back: fridge now, shop later. Around: shop only, toss the carton."