“Your Redis server suddenly goes down. Every request now hits the database. Database CPU reaches 100%. What would you change?” The hard part is not detecting that Redis is down; it is stopping the fallback from becoming a database outage of its own.
Most answers jump straight to “add a fallback” or “add a circuit breaker”. I wanted to know what actually happens in a Spring Boot 4 app before I answered. So I read the defaults out of the real jars, ran real Spring Data Redis against a Redis server that I killed mid-session, and simulated the database side with numbers I could control.
The short version:
With Spring Boot 4.0.7 defaults, Lettuce doesn’t fail fast when Redis dies mid-session. It queues the command and waits. My GET failed after 60,010 ms. With two settings changed, it failed in 4 ms.
While those calls wait, they hold request threads. Tomcat has 200 by default, so the app stops answering everything, not just the cached endpoints.
In a simulation of 20,000 requests over 100 keys, a naive fallback sent 20,000 queries to a 10-connection database. Single-flight sent 100. A warm in-process Caffeine cache sent 0.
Spring Framework 7’s
@ConcurrencyLimitis a built-in bulkhead, but its default policy isBLOCK. For a database under an outage you wantREJECT.The real fix is a capacity rule: the database must survive the cache being gone. Everything else is how you meet it.
What the full article covers
Why this question is the real filter
Layer 1: Redis must fail fast, and by default it doesn’t
Layer 2: the fallback is a stampede
Layer 3: single-flight, one query per key
Layer 4: a local cache that serves stale data
Layer 5: a bulkhead in front of the database
Layer 6: when Redis comes back empty
The capacity rule behind all of it
The full article, with the code and the measurements, is on Medium: https://medium.com/system-design-architecture-deep-dives/redis-goes-down-and-every-request-hits-the-database-the-spring-boot-4-answer-measured-52df22c7b855
Top comments (0)