Redis died. Should your whole site die with it?

transcript

Your Redis cluster just died. Every node. Should your whole site die with it? It really shouldn't.

A product read tries Redis first. Connection error. The exception climbs up the stack. The user sees a 500. Your cache was meant to make things faster. Now it's an outage. Now handle it. That error opens a circuit breaker. Later reads skip the cache and go to the database. Slower, but up.

Normally it's closed. Every get has a 100 millisecond timeout. Five failures in a row, and it opens. Reads skip Redis completely. So you stop paying a timeout on every request to a dead cache. After 30 seconds, one trial request. Works? Close. Fails? Open again.

But here's the catch. Your caching pattern decides if this is even possible. Read-through: the cache loads from the database. If it's down, reads have no path. Cache-aside: the app owns the database call. A dead cache is just a miss.

Every get returns hit, miss, error, or skip. It never throws. And it counts each one, so you still see your hit ratio. A dead cache should make you slower. Never broken.

Full breakdown in the lecture.