A cache trades freshness for speed
Every cache is a bet: this answer will still be good later. Browsers bet. CDNs bet. APIs bet. Databases bet. Your app probably bets several times before the user sees a pixel. Most of the time, that is why everything feels fast.
Flip the switches and watch the story turn into a tiny operating model.
Systems stories get more interesting when you can feel the pressure move through the stack.
HTTP caching is mostly instructions
The server sends a response with caching instructions. Cache-Control can say how long a response is fresh, whether a shared cache may store it, and whether the client must revalidate before reuse. ETag gives the client a cheap way to ask, "is my copy still good?"
Five minutes fresh, one minute stale while the cache quietly checks again.
Stale data is a time-travel bug
The painful cache bugs are not crashes. They are contradictions. The admin sees the new plan. The user sees the old plan. Support sees both depending on which tab they opened first. That is not one bug, it is a map of who is reading from which time.
Follow the age before changing code.
Cache policy is product behavior
Some data can be old for a while. Logos, docs, marketing pages, and public assets love long caches. Account state, payments, permissions, and safety decisions need a tighter story. The right question is not "can we cache this?" It is "how wrong can this be, and for how long?"