What is caching? Why it's fast, and why it goes stale

The fastest work is the work you don't redo. A cache remembers the answer so it can skip straight to it.

A cache keeps a ready-made copy of an answer, so the next request gets it instantly instead of doing the work all over again.

MDN: "A cache (web cache or HTTP cache) is a component that stores HTTP responses temporarily so that it can be used for subsequent HTTP requests as long as it meets certain conditions."

The deal: the first visitor pays for the work, and everyone after gets the saved copy, fast. That's where most of the web's speed comes from, and it's why a busy page can feel instant.

The classic bug is the flip side: a cache can serve something out of date. You change a page, but visitors keep seeing the old one until the copy expires. "Why does it still show the old version?" is almost always caching.

We live this daily: this site serves most pages from a per-location cache, and every deploy wipes it, so the first visitor after a deploy triggers a fresh render. We tune how long each copy lives to keep pages both fast and current. That lifetime is the whole trade-off.

That lifetime has a name (a TTL). Short means fresher but slower; long means faster but staler. Choosing it well, per kind of content, is most of the art of caching.

Try it with the rules off. Picture the first visitor waiting two seconds while the answer is computed, and the next thousand getting it in a blink from the cache. Then picture fixing a typo, and none of them seeing it until the copy expires. That's caching, in both directions.

Next in when it breaks: Queues and background jobs.