In this chapter
We'll define what a cache actually is — a real, general pattern of trading freshness for speed, already met at every layer from Act 1's memory hierarchy to Act 2's browser storage — and find the uncomfortable real fact behind GreenMart's stock-count incident: an intermediate proxy had been caching pages by default, with nobody at GreenMart ever deciding it should.
The Problem in Real Life
A customer orders the last unit of a popular product. The product page said "In Stock — 3 left." It had said that for eleven minutes after the item actually sold out. Mike is furious. "We don't even have a caching system. How can something be 'cached' if nobody built one?"
Sarah pulls up the response headers on that exact page. "Nobody built one on purpose," she says. "That doesn't mean one isn't there."
We never built a caching system. So how did the page show old data?
Mike
A Cache Someone Designs vs. A Cache That Just Happens
Freshness traded for speed, always
A cached answer is a copy from the past — that's not a bug, it's the entire, deliberate bargain every cache makes.
A cache doesn't need a decision to exist
Caching is often infrastructure's own reasonable default — a real cache can be live in production with nobody having chosen to add one.
What Is a Cache?
A cache is a real, deliberately simple idea: keep a copy of something expensive to get, somewhere faster to reach, so the next request doesn't pay that real cost again. It's not one specific product or technology — it's a pattern, and once GreenMart understands the pattern, it becomes clear caches show up whether or not anyone at GreenMart ever chose to add one.
- The one real trade this whole Act is about. Every cache trades freshness for speed — a cached answer is, by definition, a copy made at some point in the past, and it's only ever as current as the moment it was captured. This isn't a flaw to be engineered away; it's the entire, real bargain a cache makes, on purpose, in exchange for not paying the original cost again.
- GreenMart has already met this idea, more than once. The memory hierarchy (Act 1) is a real cache stacked on a real cache — RAM is a faster, smaller copy of what disk holds; a CPU's own cache is a faster, smaller copy of what RAM holds. A browser's own automatic HTTP cache and the Cache API (Act 2) are both real caches too — copies of network responses, kept somewhere faster than fetching them again. None of these are separate ideas; they're the same one real pattern, showing up at a different layer each time.
- A cache doesn't require a decision to exist. GreenMart's own product page turned out to be going through an intermediate proxy — placed in front of the app server for an unrelated reason, months earlier — that was applying its own default, sensible-sounding caching behavior to any response that didn't explicitly say otherwise. Nobody at GreenMart configured a cache. A cache existed anyway, because caching is often the reasonable, low-effort default behavior of the real infrastructure sitting between a request and its answer, not something that only exists when deliberately built.
- What makes something worth caching in the first place. Not everything benefits from a cache — a good candidate is real data that's genuinely expensive to produce (a slow query, a heavy computation, a network round-trip) and read far more often than it changes. GreenMart's own stock count fails that second real test badly: it changes constantly and matters the instant it's wrong, which is exactly why caching it carelessly caused real, direct harm — a promise on-screen ("3 left") that was already false.
GreenMart now has the real, general shape of the problem: not "we have a caching bug," but "a cache existed, invisibly, and nobody had decided how stale its data was allowed to get." The rest of this Act builds the real, deliberate vocabulary to control exactly that.
Key Takeaway
A cache is any copy kept somewhere faster to save paying a real cost again — and because caching is often a system's own reasonable default behavior, one can exist in a real, working product without anyone ever having decided to add it.
Why This Matters
Every layer of GreenMart's real infrastructure — a proxy, a CDN, a browser, even the database's own internal buffers — is capable of caching something, often by default. Understanding caching as one general pattern, not a specific tool GreenMart either has or doesn't, is what turns an invisible, accidental cache into one GreenMart can actually see, reason about, and control.
GreenMart now has the real, general definition of a cache — and the uncomfortable fact that one was already live, invisibly, on the exact page that just caused real harm. The next chapter goes deep on the real question that actually matters: how does anything, anywhere, know when a cached copy has gone stale?