Redis and Spring Cache: The Caching Abstraction in Practice

Picture the little convenience store behind your school campus. Buy a bottle of water and it is either on the shelf — three seconds — or the clerk has to fetch it from the back-room warehouse, which takes two minutes; if the warehouse has none either, they phone the supplier, and that is half an hour away. Asking a database for a row is that errand: slow, and during a sale tens of thousands of people send the same errand at once, which is how a warehouse gets carried off. A cache does something very plain: put the frequently asked items on the shelf so most requests never leave the shop. The price is that once the shelf and the warehouse disagree (the data changed, the shelf did not), you now have to manage two copies of the truth. That is what this article is about: how to stock the shelf (read/write paths and annotations) and what to do when stocking goes wrong (penetration, breakdown, avalanche, consistency).

Five words, one line each (used throughout):

• Cache: a copy that is easy to grab but may be stale, kept somewhere far faster than the database (usually in memory)
• key: the address label of that copy, e.g. app:user::42. Every lookup depends on it — get the label wrong and you hand someone else's data to the wrong person
• TTL: the expiry date on that label (time to live). When it lapses the copy is voided and the next read must re-check reality; no TTL means permanently stale
• Refill (go back to source): the trip to the warehouse when the shelf is empty. The whole craft of caching is "refill as rarely as possible, but always from the right place"
• Serialization: packing a Java object into bytes or JSON so it fits into Redis, and unpacking it again. Pack it badly and redis-cli shows you nothing but garbage

That animation draws the happy path and four failure scenes on one route: the first two steps are identical for every request, and the fork happens at step two — "is the key actually in the cache?". To locate a production incident fast, first recognise which branch you are on; the table in Section 2 hands out the matching cure.

After this article you should be able to answer three questions:

• I added a cache, so why is the endpoint still slow? (Is it genuinely missing, or hitting yet still querying the database?)
• Operations changes a price in the admin console — when will users see it, and how do I force that delay into a range I choose?
• After rewriting @Cacheable as a this.getXxx() self-invocation it silently stops working. What single log setting proves it on the spot?

Caching works because of one plain fact: memory access and disk access differ by three to five orders of magnitude. Put the common operations side by side and the gap is obvious:

A MySQL query walks the whole chain: parse the SQL, build an execution plan, descend the B+ tree, possibly do a table lookup, then ship the result over the network. Redis is a single hash lookup in memory. The difference is not "a bit faster" — it gets amplified by concurrency: at 1000 QPS, hitting MySQL means the database serves a thousand queries a second, while hitting Redis may never touch the database at all.

What does "slow" actually look like inside a real request? The lab below carries one request from the entry point all the way to the database. Switch to the "Slow request" position and watch which layer the latency piles into — see that clearly and you know which segment the cache is supposed to shield, instead of slapping @Cacheable onto every endpoint you meet:

But there is no free lunch — once you introduce a cache, the data exists in two places, and three classic failures come with it.

Three rows are quick to read, but during an incident all you have is one sentence of symptoms. So here the two columns are laid out side by side — failure fingerprint on the left, matching first medicine on the right — worth pinning above your desk rather than memorising three times:

The breakdown scene: at 8 p.m. sharp, the sale starts. A hit product's cache key has a 3600-second TTL, and it was written exactly one hour ago — so on the hour, that key expires. Tens of thousands of requests discover an empty cache in the same millisecond and all stampede toward the database for the same row, which saturates the database with a single-row query, exhausts the connection pool, and takes the product page down. Note: the database was not broken; it was sold out by its own caching strategy.

Here is the code behind two of the fixes. First, penetration and breakdown:

An avalanche usually needs no code — strategy is enough to blunt it:

• Randomized TTL: write with TTL + random(0, 300) seconds to spread expiries instead of a synchronised burst
• Multi-level cache: local Caffeine plus Redis, so a Redis hiccup still leaves the local layer shielding the DB
• Rate limiting and fallback: add a circuit breaker (e.g. Resilience4j) in front of the database; better to reject a few requests than to avalanche it

The three fixes above are scattered through code, while a real ticket hands you a single sentence of symptoms. So instead of another table, play a round: the left column quotes what tickets actually say, the right column is the diagnosis plus the first medicine — a wrong pick explains itself on the spot, which beats memorising rows.

Meet Redis's "five blades"; together they cover nearly every caching scenario:

Integration is one starter and a few lines of config:

That one line is the minimum. A real project also needs the datasource, the serializers and the monitoring endpoint next to it — tick the boxes and watch what the dependency tree grows, paying attention to the scope difference between mysql and h2 (the second one should never live outside tests):

Writing the whole file is harder than it looks: address, timeout, pool and serialization land in different sections. **Tick Redis + datasource + logging + profile and see where spring.data.redis. and logging.level each end up* — the pool cap in Section 3 and the "mass invalidation" row of the error table both start on these lines.

Spring Boot auto-wires two templates, and their difference is the first trap a beginner hits:

Many people start with this:

Then they open redis-cli and see:

That leading \xac\xed is exactly the Java serialization magic number (0xACED). JDK serialization writes the fully qualified class name and field metadata alongside the data, so problems pile up: unreadable content, bloated size, and the moment a class name or field changes, old data fails to deserialize — plus it is a notorious source of deserialization vulnerabilities.

The fix is JSON serialization:

Now the same key in redis-cli becomes:

What makes caching pleasant in practice is Spring Cache, an annotation-based abstraction that removes the "check cache -> query on miss -> refill" boilerplate entirely. It is enabled with one annotation:

Four core annotations, each with its own trigger timing:

The most common shape:

The SpEL key syntax is where people stumble; the common expressions:

All of those rules come from one execution path. Spread it out as a single-step run: the seven lines on the left, live variables and call stack on the right. Press step repeatedly and watch box ⑤ — on a hit your method body does not run at all — because that single fact is the origin of the first trap in Section 9 and of the data-mixing cell in the sandbox:

The annotations are pleasant, but they have one hard boundary: a cache annotation can only cache "the return value of one method". The moment you need an operation rather than a result — reading many keys at once (MGET/Pipeline), renewing one specific key, grabbing a lock to rebuild exclusively, patching just two fields of an object, or running a Lua script atomically — you go back to RedisTemplate. The picture below sets both roads side by side; note especially the fourth line on the left, because annotations ride on a proxy, self-invocation kills them silently; hand-written code has no proxy and therefore no such trap:

The default RedisCacheManager never expires — a frequent source of incidents. To set a TTL, a shared key prefix, or per-namespace policies, customize it:

How long a TTL should be is the one genuine knob in caching, and its two ends each hold a different failure hostage: the left end bites memory and freshness, the right end bites the database:

First, draw the two paths clearly (see Figure 1 at the top). The core conclusion in one line: reads go "cache first", writes go "update the database, then delete the cache" — that is the Cache-Aside pattern.

Why "delete the cache" rather than "update the cache"? One concurrent scenario explains it:

"Update the cache" copies the database's write concurrency straight onto the cache, and the ordering of two writers cannot be guaranteed, so stale data appears. "Delete the cache" reduces the problem to a single atomic action, at the cost of one refill on the next read — one refill buys away the inconsistency risk.

That T1–T4 table is four lines of text; the animation plays it in order. Watch frame ④ — the overwrite happens with no exception and no log line, which is exactly why this class of bug is the hardest to catch:

Then, is "delete the cache first, then update the database" fine? It has its own race (a reader refills the old value after the delete but before the update). So the more robust order is Cache-Aside's "update the DB first, then delete the cache", backed by delayed double delete:

Delete-versus-update is only one cell inside five read/write strategies. Spring Cache defaults to the first (aside); the other four each have their own fit and their own way of failing. Click through them, and each box answers the one question that matters: who is responsible for filling the cache?

The mutual-exclusion cache rebuild above is a distributed lock in embryo. A usable lock has three elements: atomic acquisition, expiry as a backstop, and the ability to delete only your own lock:

Cache, transaction and log failures all stem from the same proxy mechanism; the demo below lets you see exactly what self-invocation bypasses:

The three traps in Section 9 are prose, but each has a shape you can actually see. The five labs below answer, in order: how do the three failures differ in timing? What does it look like when the cache stops shielding the database? How do you learn that Redis is alive before your users do? Which of the three rate limiters survives an avalanche? And what is the relationship between those MyBatis cache layers and Spring Cache?

The first lab is the star. Cycle through hit → miss → key → pen → bust while replaying the matching game in Section 2:

The second turns the sentence "the cache holds read pressure outside the database" into a curve you can watch. Compare "Idle hit" with "Queue at the limit" and feel how the waiting queue grows as the hit rate falls from 95% to zero:

The third answers a very practical anxiety: Redis dies — how do I know before my users do? The Actuator health endpoint aggregates the Redis connection state into a DOWN, which with monitoring becomes the earliest alarm you can get:

The fourth turns Section 2's "put a limiter in front of the database" into concrete algorithms. When an avalanche hits, a fixed window lets roughly double the traffic through at its boundary, a leaky bucket is always smooth but cannot absorb bursts, and a token bucket permits bursts provided you size it — switch to "Choosing and bursts" and the three shapes are drawn side by side:

The fifth settles a question that never stops appearing in comment sections: what is the relationship between MyBatis's first/second-level caches and Spring Cache? On the shared-cache position you see it surviving across sessions and, by default, invalidating a whole namespace — a different model from @CacheEvict deleting one precise key, and running both layers at once can hide stale reads:

Once you are bored of buttons, type the commands yourself. This console talks to the same in-browser Java kernel and every reply is computed there — start with ping to confirm the container is up, then run the three failures and one connection timeout:

A wrong strategy shows up late, and by then the database is already taking the hits. This sandbox turns "how stale is acceptable" into one switch; each position shows the TTL, the concurrency protection and the metric to watch, side by side:

A warm-up on the pair of concepts most often stated backwards in interviews:

Now a combined question tying the annotation mechanics of Section 5 to the trap in Section 9:

Beginners hit four walls here: cannot connect, cannot read (garbage), reads the wrong thing (mixed data), and the nastiest of all — nothing happens at all. Every fragment below can be pasted verbatim into a search engine.

The first row is the one beginners hit most and misjudge most: it looks like a wrong password or a dead Redis, when it is usually just a localhost inside a container pointing at the container itself. Do not read the answer — click the frame you think is guilty:

Build the smallest possible "two reads, one query" scene. No Redis required — Spring's built-in ConcurrentMapCacheManager shows every mechanism of these annotations. Fully runnable code:

Expected output (db hits must be 1):

The absence of a third [db] SELECT is the proof that the second read was served from cache. Comment out @EnableCaching, rerun, and you get db hits = 2 with not a single error in the log — the live version of the silent failure listed in Section 13.

Goal: prove that self-invocation bypasses the cache proxy.

Hint: add exactly one method to ProductService: public java.util.List<Product> findTwice(Long id) whose body is return List.of(find(id), find(id)); (calling find directly is this.find(id)), then call svc.findTwice(9L) twice from main.

You should observe: the first call prints two [db] lines where you expected one, and the second call prints two more — four database queries in total. The cache is not broken; those four calls never reached the proxy. Now move findTwice into a separate SearchFacade bean that injects ProductService, and the [db] count collapses to one. Write both SQL-line counts in your notes — that is the evidence for the first trap in Section 9.

Replace Tier 1's map cache with real Redis, then defend against each of the three failures using the table in Section 2.

Acceptance checklist:

• [ ] KEYS app:product* in redis-cli shows readable JSON with a prefix, not \xac\xed binary
• [ ] TTL works: TTL app:product::1 returns a positive number, and different cacheNames carry different TTLs
• [ ] Penetration defence works: after querying 20 non-existent ids, Redis holds null markers for them with TTL ≤ 2 minutes
• [ ] Breakdown defence works: delete the hot key, read it from 50 threads at once, and the SELECT log line prints exactly once (the mutex held)
• [ ] Avalanche mitigation works: sample ten batch-written keys and their TTLs differ (visible jitter)
• [ ] Updates follow "write the database, then delete the cache", and you can explain why updating the cache is wrong (see the T1–T4 table in Section 7)
• [ ] /actuator/health lists the redis component; stopping Redis flips it to DOWN without the whole application returning 500 because of the cache