When is in-process caching worth it over Redis?

When the data is small, read constantly, and can be a little out of date on some servers and not others. Feature flags, configuration and small lookup tables qualify. Anything a user would notice being inconsistent between two page loads does not.

How do I invalidate an in-process cache across servers?

You cannot do it directly, which is the point. The usual approach is a short expiry so every server converges within a known window, or a pub/sub message that tells each process to drop its own copy. Once you are running the second one you have most of the complexity of a shared cache and might as well use one.

Why not just use a HashMap?

Because it has no size limit and no expiry, so it grows until the process runs out of memory, and it never notices that a value has gone stale. Caffeine gives you both in one builder, and the failure it prevents shows up weeks later as an out-of-memory error nobody connects to the cache.

Cachingchapter 2 of 8 · 2 lessons

Client and In-Process Caches

The two places a copy can sit that are faster than Redis, and harder to correct.

← All chapters View in cheatsheet

Two of the four places a cache can live get a chapter to themselves later on. The shared cache is Redis, and the edge is the CDN.

The other two sit closer to the reader than either, and both are faster than Redis for the same reason: no network is involved. That is also what makes them awkward. A copy you cannot reach is a copy you cannot correct.

Lessons

2 in this chapter

Client-Side CachingThe fastest cache is the one on the user's device, and the one you can never take back.2 min
In-Process CachingA map in your own memory, faster than Redis, and wrong on nine servers out of ten.2 min