Spring Redis cache outage: choose failure behavior per operation

Last updated: 1 Oct 20264 min read

tutorial

An unavailable Redis cache should have an explicit response policy; cache reads and shared sessions have different failure costs.

Classify the dependency

A public catalog read may continue by loading from the database when Redis is down, provided the database can absorb the extra load. A session lookup cannot safely invent an authenticated user when the shared session store is unavailable. A rate limiter might fail closed for a protected write but use a carefully bounded emergency policy for a read-only endpoint. One global catch-and-ignore CacheErrorHandler does not express these differences.

Protect the fallback

If every replica bypasses cache at once, the backing store sees a synchronized miss storm. Limit concurrent loads, keep a short timeout, and shed excess requests before database capacity is consumed. Local synchronized loading helps only within one process. Gateway limits can protect the edge, while readiness must reflect whether the operation can still meet its contract.

Test both recovery directions

Disconnect Redis under steady load, verify the chosen HTTP status and backing-store saturation, then reconnect it. Check that keys refill at a bounded rate and that stale values are not accepted after a write. For shared sessions, verify failover at the login boundary separately from cache behavior. The pseudocode is a policy sketch, not a generic cache interceptor.

Implementation sketch

PriceQuote quote(String tenantId, String sku) {
    try {
        return cacheLookup(tenantId, sku)
            .orElseGet(() -> boundedDatabaseLoad(tenantId, sku));
    } catch (RedisConnectionFailureException unavailable) {
        return boundedDatabaseLoad(tenantId, sku);
    }
}
// Bound concurrent database loads before enabling this policy.

Cost and verification

Bypassing cache shifts latency and load to the source. Concurrency caps and a short deadline protect that source but may reject requests that would otherwise wait.

Common Mistakes

Do not swallow every Redis error and call the operation successful.
Do not treat an absent session as an authenticated principal during failover.
Do not reopen the entire database floodgate after Redis reconnects.