How a Single-Writer Cache Pattern Stops Database-Crushing Stampedes

A backend engineer describes how a sudden traffic spike—not a cyberattack—drove their API's database CPU to 99% and triggered cascading 500 errors. The root cause was a cache stampede: when a hot cache key expired, dozens of service instances simultaneously attempted to recompute the same value, overwhelming a sharded Postgres database. The team's existing in-process cache with a simple TTL offered no protection against this thundering-herd effect. The solution was a single-writer pattern using a distributed Redis lock, allowing only the first request on a cache miss to rebuild the value while others either wait briefly or receive a slightly stale response. This approach isolates builder failures, preserves concurrency, and prevents total outages during invalidation windows.