In this chapter
We'll turn all nine of this Act's real mechanisms — what makes something worth caching, invalidation strategies, eviction, write strategies, HTTP headers, ETags, CDNs, and stampede protection — into one real, ordered decision process, and close with GreenMart's own stock count, genuinely and fully fixed.
The Problem in Real Life
Sarah stands in front of a whiteboard that's genuinely full now — invalidation strategies, TTL, eviction, write strategies, HTTP headers, ETags, CDNs, stampedes. "We started this Act with one wrong number on a screen," she says. "We're closing it with a real, repeatable process for every caching decision GreenMart makes from here on."
Mike looks at the board, then back at the original incident. "So — walk me through it. What actually should have happened?"
Walk me through it — what should we actually have done differently?
Mike
Nine Real Mechanisms vs. One Real Decision Process
Five real questions, not nine separate topics
Candidate check, invalidation strategy, eviction fit, explicit header, and stampede readiness — the same five questions decide every caching choice.
The stock-count incident, finally fully fixed
Write-through invalidation plus an explicit private, no-store header — a real, deliberate fix, not an accidental default.
When Should You Cache?
Every mechanism this Act covered answers a genuinely different piece of the same real question: should this specific data be cached, and if so, exactly how? Put together, in order, they form one real, repeatable decision process — not nine separate topics to memorize.
- Step one — is this even a good candidate? (Chapter 1.) Real, expensive to produce, and read far more often than it changes — that's the real bar. GreenMart's stock count genuinely failed the second half of that bar: it changes constantly, which should have flagged it for extra care from the very start, not a default proxy TTL.
- Step two — how will the cache learn it's stale? (Chapters 2, 3, 5, 7.) Time-based (TTL alone), event-based (write-through, updating the cache the instant real data changes), or validation-based (ETags, checking cheaply before trusting). GreenMart's real, correct answer for the stock count: event-based, via write-through — the cache learns the truth the instant it changes, not up to 15 minutes later.
- Step three — what happens under real capacity pressure? (Chapter 4.) LRU, LFU, or a simpler policy, chosen to fit the real, observed access pattern of that specific data — not a default nobody actually chose.
- Step four — which layer, and how is it explicitly declared? (Chapters 6, 8.) A real
Cache-Controlheader, sent deliberately, controlling every layer at once — browser, shared proxy, and CDN edge node alike. GreenMart's real, correct header for the stock count:private, no-store— never cached by any shared layer, full stop. - Step five — what happens if this becomes genuinely popular? (Chapter 9.) High-traffic cached data needs real stampede protection — locking, jittered TTLs, or refresh-ahead — decided before the first flash sale, not diagnosed after the database already fell over.
| Data | Cache it? | Invalidation | Cache-Control |
|---|---|---|---|
| Live stock count | No shared caching | Event-based (write-through) | private, no-store |
| Product description | Yes | Time-based (long TTL) | public, max-age=86400 |
| Product image | Yes, aggressively (CDN) | Time-based (very long TTL) | public, max-age=31536000 |
| Flash-sale landing page | Yes, with stampede protection | Time-based + jitter/refresh-ahead | public, max-age=60 |
The same real decision process — candidate check, invalidation strategy, eviction fit, explicit header, stampede readiness — applied consistently, produces genuinely different, correct answers for genuinely different kinds of data.
GreenMart closes this Act having done, for real, what Chapter 1 only diagnosed: turned "a cache existed and nobody designed it" into a specific, deliberate decision, made the same real way, for every kind of data GreenMart will ever need to cache.
Key Takeaway
"Should we cache this?" was never one question — it's five real, ordered ones, and this Act just handed GreenMart all five, proven against a real incident from start to finish.
Why This Matters
Every future feature GreenMart ships that touches real, changing data — a new inventory system, a personalized recommendation feed, a live order-status page — now has a real, repeatable caching decision process behind it, instead of quietly inheriting whatever default the nearest proxy or CDN happens to ship with.
GreenMart closes Act 4 with the stock-count incident actually, fully fixed, and a real framework for every caching decision still to come. Act 5 turns to a different real limit entirely: GreenMart's product images and receipts outgrowing what a single machine's disk can hold at all.