Day 3 of 30: Caching, and Why Invalidation Really Is That Hard

Recap

Day 1 was the big picture (client-server, scaling, latency vs. throughput). Day 2 went into databases (SQL vs. NoSQL, replication, sharding). Today's topic was one I thought I already understood: caching. Turns out I only understood the easy 20% of it.

Why Caching Exists

The core idea is simple: fetching data is expensive (database queries, network calls, computation), so you store a copy of the result somewhere faster and cheaper to access, and serve from that copy instead of redoing the work every time.

But "store a copy somewhere faster" hides a lot of decisions: where do you store it, how long do you keep it, and how do you know when that copy is no longer accurate?