کش: Caffeine و RedisCaching: Caffeine & Redis

Let's accept one simple truth up front: the fastest thing an application can do is the work it never does. If you already have the answer to a question, you don't need to hit the database again, recompute it again, or ask a remote service again. A cache is exactly that: a small, close-at-hand notebook where you keep frequent answers so that next time you can hand them over in nanoseconds instead of milliseconds.

In this chapter you won't just learn to slap @Cacheable on a method and move on. You'll understand what pain a cache cures, why it sometimes becomes the source of the worst bugs, what the two reference tools of the Java world — Caffeine for local caching and Redis for distributed caching — actually do, when to pick which, and how to talk about the hard trade-offs of caching in a senior interview.

Part 0 — a few words you must feel before any code

Before we get to code, a few terms recur throughout this chapter. Let me plant them with analogies right now.

A few words you'll see relentlessly from here on:

• Hit: the answer you wanted was in the cache and handed straight back. Like finding the salt on the counter.
• Miss: the answer wasn't in the cache, so you had to go to the real source (database, service, computation). Like a trip to cold storage.
• Hit ratio: the percentage of requests that were hits. A cache with a 95% hit ratio means 95 of every 100 requests never even reached the database. This is the single most important health number of a cache.
• Eviction: when the cache fills up, it must throw something out to make room for a newcomer. Which one it throws out is the "eviction policy" — the soul of this chapter.
• TTL — Time To Live: how long, at most, an entry is allowed to stay in the cache, regardless of how often it's read. Like the expiry date on a carton of milk.
• Evict vs expire: "expire" means its time ran out (TTL); "evict" means room ran out and we pushed it out. Two different reasons to leave.
• Stale: data that's still in the cache but no longer matches the source — like a price that's 100 in the cache but has become 120 in the database. The core trade-off of caching is always with this "staleness."

Why cache at all? The story of the numbers

Caching isn't a decorative optimization; it comes from a physical reality: not all memory is equally fast. Between reading from the application's local memory and going to a database over the network, there are several orders of magnitude of difference.

The gap between a local cache and a database is roughly fifty-thousand-fold. Now imagine a product page opened a thousand times per second, each time reading the same static product info from the database. Cache it, and a thousand queries per second collapse to nearly zero, and the database breathes.

But as we said, this speed isn't free. The moment you keep a copy of data somewhere else, you have two versions of the truth — and wherever there are two versions of the truth, there's a chance of divergence. So let's first see how data enters and leaves the cache.

Cache patterns: how data moves

Who is responsible for filling the cache and writing to the database creates different patterns. Confusing these is the root of a lot of muddled thinking.

1) Cache-aside (lazy loading)

The most common pattern, and the one you usually write when caching by hand. Here the application code is responsible for everything; the cache is just a simple key-value store standing beside you (hence "aside").

public Product getProduct(long id) {
    // 1) check the cache first
    Product cached = cache.getIfPresent(id);
    if (cached != null) {
        return cached;              // hit
    }
    // 2) miss — go to the real source
    Product fromDb = productRepository.findById(id);
    // 3) put the result back for next time
    if (fromDb != null) {
        cache.put(id, fromDb);
    }
    return fromDb;
}

Its strength is simplicity and total control; its weakness is that you must repeat this "three-step pattern" everywhere by hand, and if you forget, you get a bug. Its bigger problem, which we'll see later: if a thousand requests simultaneously miss, all thousand storm the database at once (that's the cache stampede).

2) Read-through

Here you no longer write those three steps yourself; you tell the cache "if you don't have it, call this function and fill yourself." The cache becomes the read intermediary. Caffeine's LoadingCache is exactly this.

LoadingCache<Long, Product> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .build(id -> productRepository.findById(id));  // the "load function"

// now you just say:
Product p = cache.get(42L);   // if absent, the cache calls the loader and stores it

The subtle-but-important difference from cache-aside: the "how to fill" logic lives in one place beside the cache, not scattered across every call site. And more importantly — as we'll see — a loading cache usually coalesces concurrent requests for the same key, meaning the load function runs only once even if a thousand threads want that key at the same time.

3) Write-through

The write-side mirror of read-through: every time you write, you update both the cache and the database synchronously and at the same time. Benefit: the cache never falls behind the database. Cost: every write must wait for the database, so writes get slower.

4) Write-behind / Write-back

Here you write into the cache first and return immediately; the database write happens later, asynchronously and often in batches.

5) Refresh-ahead

A pattern whose name doesn't fool you: the cache proactively reloads a "hot" entry in the background before it expires, so the user never hits a miss. Caffeine provides this via refreshAfterWrite, which we'll see shortly.

Eviction policies: when the cache fills, which one goes?

A cache is bounded. When it's full and a newcomer arrives, it must sacrifice one. Which one you sacrifice directly determines the hit ratio — and that's what separates Caffeine from a plain HashMap.

LRU — Least Recently Used

But LRU has a famous weakness: it collapses under a sequential scan. Imagine your cache full of hot data, and someone reads the entire table once (say, a heavy report). That scan brings in thousands of one-shot entries, each counted as "recently used," and pushes out all your actual hot data. LRU can't tell that those were requested only once.

LFU — Least Frequently Used

LFU says: "whatever was used least often, goes first" — deciding by count of accesses, not by time of last access. This is more scan-resistant (a one-shot item has frequency 1 and is sacrificed quickly). But LFU has two weaknesses of its own: keeping a counter for everything costs memory, and it gets stuck in the past — something that was very hot last month but is cold now still has a high count and stubbornly stays in the cache.

W-TinyLFU — Caffeine's smart choice

This is where Caffeine shines. Caffeine — originally a rewrite of Guava's cache and today the reference local-caching library in Java (stable 3.x line, requiring Java 11+) — uses an algorithm called W-TinyLFU that takes the best of both worlds.

The workflow of W-TinyLFU goes like this — and it's worth understanding, because it's gold in a senior interview:

1. Admission window: every new entry first enters a small LRU (about 1% of the cache). This gives fresh data a chance to prove itself without immediately competing with the veterans.
2. Admission filter: when an entry wants to move from the window into the main space, TinyLFU judges like a doorman: "is this newcomer's estimated frequency higher than that of the current victim in the main space?" If yes, it's admitted and the victim goes; if no, the newcomer itself is rejected. This is what neutralizes scans — a one-shot item has low frequency and the doorman turns it away.
3. Main SLRU space: the main space is itself a Segmented LRU with two segments: a "probation" segment and a "protected" segment. An entry that is read again is promoted from probation to protected. This combines frequency (how much) and recency (when).
4. Counter aging: the frequency sketch periodically halves all counters (aging), so that the LFU problem of "last month's champion stubbornly staying" is solved. Past hotness slowly fades.

The result: on real workloads, Caffeine achieves a hit rate close to the ideal clairvoyant algorithm (Bélády's), while its memory overhead is negligible. You usually tune none of this by hand; you just give a maximumSize and Caffeine handles the rest intelligently.

Caffeine in practice: building and tuning

Let's start with a simple cache and enrich it layer by layer. The dependency (current stable from the 3.x line):

<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.2.2</version>
</dependency>

A manual (cache-aside) cache, with a size cap and stats:

import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;
import java.time.Duration;

Cache<Long, Product> cache = Caffeine.newBuilder()
    .maximumSize(10_000)                     // size-based eviction with W-TinyLFU
    .expireAfterWrite(Duration.ofMinutes(5)) // TTL
    .recordStats()                           // count hits/misses for monitoring
    .build();

Product p = cache.getIfPresent(42L);         // may be null (miss)
cache.put(42L, product);

LoadingCache — the read-through version

If you hand the load function to Caffeine, you no longer write those three cache-aside steps yourself and — more importantly — you get automatic request coalescing for free:

import com.github.benmanes.caffeine.cache.LoadingCache;

LoadingCache<Long, Product> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(Duration.ofMinutes(5))
    .build(id -> productRepository.findById(id));   // load function

Product p = cache.get(42L);   // if absent, loads and stores; never null unless the loader returns null

TTL vs TTI: expireAfterWrite vs expireAfterAccess

Here's one of the most common interview misconceptions. There are two kinds of time-based expiry:

Cache<String, Session> sessions = Caffeine.newBuilder()
    .expireAfterAccess(Duration.ofMinutes(30))   // TTI: stay alive while active
    .build();

Cache<String, ExchangeRate> rates = Caffeine.newBuilder()
    .expireAfterWrite(Duration.ofMinutes(1))     // TTL: an FX rate is worthless after a minute
    .build();

Rule of thumb: for data that goes stale at the source (FX rates, prices, inventory) use expireAfterWrite/TTL — no matter how often you read it, after a minute it's no longer trustworthy. For data that should be dropped only when abandoned (a user session, transient data) use expireAfterAccess/TTI.

refreshAfterWrite: the subtle difference from expiry

LoadingCache<Long, Product> cache = Caffeine.newBuilder()
    .refreshAfterWrite(Duration.ofMinutes(1))    // after 1 min, refresh in background
    .expireAfterWrite(Duration.ofMinutes(10))    // but after 10 min, don't serve stale
    .build(id -> productRepository.findById(id));

AsyncLoadingCache and asynchronous caching

If you work in a reactive or CompletableFuture world, Caffeine also has an async version that stores the result as a CompletableFuture — which makes request coalescing work naturally over futures:

AsyncLoadingCache<Long, Product> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .buildAsync((id, executor) ->
        CompletableFuture.supplyAsync(() -> productRepository.findById(id), executor));

CompletableFuture<Product> future = cache.get(42L);

Local vs distributed: Caffeine vs Redis

So far we've talked about Caffeine, a local in-process cache: the data lives right inside that JVM's memory. The fastest thing possible. But it has a big problem that only shows up when you spin up multiple instances of your application.

Redis is an external, shared in-memory key-value data store that lives on the network. All instances of your application connect to a single Redis, so they share one version of the truth. The cost: every access is now a network round trip (milliseconds, not nanoseconds) and data serialization (turning a Java object into bytes and back).

Redis and its Java clients

Redis (short for REmote DIctionary Server) isn't just a key-value cache; it's an in-memory data store with rich data structures: strings, hashes, lists, sets, sorted sets, and more. But its most common role is still the cache.

The three main Java clients you should know:

• Lettuce: Spring Boot's default client. Built on Netty, asynchronous and reactive, thread-safe; a single connection can be shared across many threads. A good default choice.
• Jedis: the older, simpler client — blocking and synchronous. Not thread-safe, so it's usually used with a connection pool. Simple and well-known.
• Redisson: higher-level; instead of raw commands, it gives distributed implementations of Java structures (RMap, RLock, distributed semaphore, queue). Excellent when you need distributed locks or complex structures.

Simple usage with Lettuce (directly, without Spring):

import io.lettuce.core.RedisClient;
import io.lettuce.core.api.StatefulRedisConnection;
import io.lettuce.core.api.sync.RedisCommands;

RedisClient client = RedisClient.create("redis://localhost:6379");
try (StatefulRedisConnection<String, String> conn = client.connect()) {
    RedisCommands<String, String> cmd = conn.sync();

    cmd.set("product:42", jsonPayload);      // write
    cmd.expire("product:42", 300);           // server-side TTL: 300 seconds
    String cached = cmd.get("product:42");   // read; null means miss or expired
}
client.shutdown();

Spring's cache abstraction: declarative caching with annotations

Writing that three-step pattern by hand everywhere is tedious and error-prone. Spring provides a cache abstraction that, with a few annotations, applies caching to methods declaratively and transparently — without polluting your method body.

First enable the abstraction and give it a provider. With Spring Boot, add the spring-boot-starter-cache dependency and put @EnableCaching on a config class. If Caffeine is on the classpath, Spring auto-configures a CaffeineCacheManager; if Redis, a RedisCacheManager.

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public CacheManager cacheManager() {
        CaffeineCacheManager manager = new CaffeineCacheManager("products", "users");
        manager.setCaffeine(Caffeine.newBuilder()
            .maximumSize(10_000)
            .expireAfterWrite(Duration.ofMinutes(5))
            .recordStats());
        return manager;
    }
}

@Cacheable — cached reads

@Service
public class ProductService {

    @Cacheable(cacheNames = "products", key = "#id")
    public Product getProduct(long id) {
        // this body runs only on a miss
        return productRepository.findById(id);
    }
}

The first call with id = 42 runs the body and caches the result; subsequent calls with the same key don't run the body at all and return straight from the cache.

@CacheEvict and @CachePut — invalidation and update

• @CacheEvict removes an entry from the cache — for when data changed or was deleted.
• @CachePut always runs the body and puts its result in the cache (declarative write-through).

@CachePut(cacheNames = "products", key = "#product.id")
public Product update(Product product) {
    return productRepository.save(product);   // both DB and cache are updated
}

@CacheEvict(cacheNames = "products", key = "#id")
public void delete(long id) {
    productRepository.deleteById(id);
}

@CacheEvict(cacheNames = "products", allEntries = true)
public void reloadAll() {
    // clears the entire products cache
}

Other annotations: @Caching to combine multiple operations on one method, and @CacheConfig to put shared settings (like a cache name) at the class level. Also condition (cache only if a condition holds) and unless (do not cache if a condition holds, evaluated against the result) give fine control:

@Cacheable(cacheNames = "products", key = "#id",
           unless = "#result == null")   // don't cache a null result
public Product getProduct(long id) { ... }

Two-tier architecture: L1 (Caffeine) + L2 (Redis)

In serious systems you often want both worlds: local nanosecond speed and cross-instance sharing. This becomes a multi-tier cache or near cache.

public Product get(long id) {
    // L1: ultra-fast local cache
    Product p = caffeine.getIfPresent(id);
    if (p != null) return p;

    // L2: shared Redis cache
    p = readFromRedis(id);
    if (p != null) {
        caffeine.put(id, p);   // populate L1 too
        return p;
    }

    // primary source
    p = productRepository.findById(id);
    if (p != null) {
        writeToRedis(id, p);   // fill L2
        caffeine.put(id, p);   // and L1
    }
    return p;
}

But two tiers bring a serious problem: L1 invalidation. When data changes, Redis (shared) can be cleared directly, but each instance has its own independent Caffeine that doesn't know. The common fix: use Redis pub/sub — when data changes, publish a message on a Redis channel; all instances subscribe to that channel and, on receiving the message, evict the corresponding entry from their own local Caffeine.

Cache stampede: the thundering herd and how to tame it

Now we reach one of the most dangerous cache phenomena, which we've alluded to many times. It has many names: cache stampede, thundering herd, dogpile.

Several proven ways to tame it:

1) Request coalescing / single-flight. Exactly what LoadingCache and @Cacheable(sync=true) give: guarantee that for one key only one computation runs while the rest queue behind it. The simplest, first line of defense — but only within one JVM.

2) Distributed lock (mutex). For a cross-instance stampede, allow only one instance in the whole cluster to rebuild the key; the rest either wait briefly or serve the previous stale value. With Redis you build this via SET key value NX PX <ms> — an atomic, timed lock:

// only one instance acquires the lock and rebuilds
boolean gotLock = "OK".equals(
    cmd.set("lock:product:42", token, SetArgs.Builder.nx().px(3000)));
if (gotLock) {
    try {
        Product fresh = productRepository.findById(42L);
        writeToRedis(42L, fresh);
    } finally {
        // safe release (only if you still own it) via a Lua script
        releaseLockIfOwner("lock:product:42", token);
    }
}

3) Probabilistic early expiration (XFetch). A subtle, beautiful technique: instead of everyone expiring at one exact instant, the closer you get to expiry, the higher the probability each request decides to rebuild the cache early (in the background). Because this decision is independent and random, usually only one of the thousand requests rebuilds early while the rest still get a valid cache. The academic formula: rebuild if now - delta * beta * ln(random()) >= expiry, where delta is the recompute time and beta (default 1.0) is a tuning parameter.

4) TTL jitter. If you fill a thousand keys together with the exact same TTL, they all expire simultaneously and create a mass stampede. The simple fix: add a bit of randomness to each TTL (e.g. 5 minutes ± 30 seconds) so expiries are spread out.

5) Stale-while-revalidate. Keep the stale data and serve it immediately, refreshing in the background. That's exactly what refreshAfterWrite does in Caffeine.

Invalidation and the consistency trade-off

We arrive at that "hardest problem." When data changes at the source, how does the cache know its copy is stale? A few strategies:

• TTL-based (expiring): the simplest. Every entry dies on its own after a while. Consistency is "eventual": the staleness window is at most the TTL. For most data this is enough and surprisingly effective.
• Event-based (explicit): when data changes, actively evict or update the cache entry (@CacheEvict/@CachePut). More precise but more fragile: you must find every data-change path and miss none — hard in practice.
• Versioned key: instead of deleting, change the key. For example product:42:v7; when the product changes, bump the version to v8. Now readers looking for v8 naturally miss, and the old key expires unused. Elegant and free of deletion coordination.

The final architectural note: caching almost always means accepting eventual consistency. The moment you keep a copy, you create a window of divergence. A good engineer's job isn't to eliminate this window (often impossible or very expensive), but to deliberately shrink it to a size that's harmless for the problem domain.

Pitfalls and best practices

Let's gather the top traps in one place — the ones that bite in real code or interviews:

• An unbounded cache = a memory leak. Always set maximumSize/maximumWeight (or a TTL); an unbounded cache will eventually throw OutOfMemoryError.
• Self-invocation bypasses the cache. Calling this.method() inside the same bean skips Spring's caching layer.
• Caching null carelessly. If you cache null uncontrolled and the source later gets a value, it stays stale; if you never cache it, you're vulnerable to penetration. Make a deliberate decision (often: cache null with a short TTL).
• Same TTL for everything = avalanche. Add jitter so expiries spread out.
• Caching a mutable object and sharing it. If the object you cached is mutable and the caller mutates it, the cached version changes too (in a local cache). Cache immutable objects or hand out copies.
• Fragile serialized keys in Redis. If you store a Java object via Java native serialization in Redis, a class change can break deserialization and — worse — open an attack surface. Use JSON or an explicitly versioned format.
• Forgetting monitoring. Without a hit ratio you don't know your cache works. Take recordStats and metrics seriously.

Best practices:

• For every cache, answer these three questions: What's the size cap? What's the expiry policy (TTL or TTI, and how long)? How do I see my hit ratio?
• Local cache for frequently read-only data; Redis for cross-instance sharing; two-tier for both.
• For stampedes, start with request coalescing (sync/LoadingCache), and add a distributed lock or XFetch for hot cross-instance keys.
• Rather than chasing perfect consistency, accept a short TTL except where staleness is truly intolerable.

Interview Questions

Now let's drill everything through real senior-interview questions. Answer each yourself first, then open the answer.