**Parent Topic**: [[Software/README]] ## The Cache as a Dangerous Dependency The original incident was a **cache stampede**: a reactive (lazy) cache where a miss triggers regeneration. When the front-page cache expired under thousands of requests per second, all of them ran the same query against the database at once, overloading it (the [[Thundering Herd Problem]]). Rebuilding, dealnews faced the question: add another reactive cache at the application server? They refused. ## Concentration Makes It Worse "Unlike on a social networking site, our traffic is concentrated: 40% of all requests are for our front page." When traffic concentrates on a few keys, a single cache failure doesn't degrade gracefully — "lots of requests will be extremely slow and this can cause problems." A reactive cache becomes "a dependency that could fail us." ## Make Cacheless Operation a Requirement Their decision: "the read-only databases and code that queried them had to be ready to go *without* a cache at the application layer." They made this a hard architectural requirement and built to meet it — verified by [[Test Production Systems Under Load]] (they turned memcached off mid-test and survived). Caching should be an optimization you can lose, not a load-bearing dependency. Enabled by [[Precompute Transformations Once]] and the [[Read-Only Replica Cluster]]. --- *Source: [[Web Operations]] (Allspaw & Robbins, O'Reilly 2010) — Ch 9 — Dealing with Unexpected Traffic Spikes*