Cache invalidation

Removing or updating cached copies when the source changes is famously hard: copies live in many places and updates race with reads. Common answers are short TTLs, deleting on write and versioned keys.

Where it shows up in real systems

  • CDN

    Images, scripts, styles and videos are cached at the edge, so most requests never reach your servers. Longer TTLs raise the hit ratio but make content updates slower to appear; an origin shield collapses cache misses from all edges into one.

    In production: Amazon CloudFront, Cloudflare, Akamai, Fastly, Azure Front Door

  • In-process cache

    No network hop, so it is the fastest cache possible, but each instance holds its own copy: memory is duplicated and invalidation is hard, so instances can disagree for up to the TTL.

    In production: Caffeine (Java), Guava cache, lru-cache (Node.js), functools.lru_cache

See it break, then fix it

Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.

Open the learning path Open the sandbox