Redis never gives you anything for free the hidden price behind every layer of cache

When I started out, caching was simple to me: API slow? Throw Redis at it, cache the thing, done. It really was fast, so I figured I understood caching. But lately, cramming in earnest for an architect interview, it finally dawned on me: that “throw Redis at it” move drags along a whole chain of problems, and if you don’t understand them, you patch one spot only to spring a leak somewhere else.

I want to retell the whole journey, because when you string it together it’s more elegant and more logical than I ever expected. And there was one line I kept hanging over my head the entire time I wrote — the classic joke of the trade:

I used to find that line funny. Now I don’t think it’s joking at all. Nearly everything thorny in this post boils down to one word: invalidation — knowing when the data in the cache has gone stale, and handling it correctly.

First: cache is everywhere

Let me be explicit about something, because I used to forget it: cache lives all over our stack, each layer solving a different problem.

The part I’m covering focuses on what backend touches most: the application-level cache, the kind where you put a Redis in front of the database to soak up read traffic. Everything below revolves around exactly that layer.

Cache-Aside, and the small detail lots of people get wrong

Let’s start with the most common pattern: Cache-Aside, aka Lazy Loading. The read flow goes like this: a request comes in, look in the cache first; if it’s there, return it right away (cache hit); if not, go down to the database, fetch it, stuff it into the cache, then return it (cache miss). Simple, and it’s popular for a reason I find genuinely valuable: if Redis dies, the app still runs — just slower, going straight to the DB. The cache is a speed accessory, not a lifeline.

The write flow, when data changes, has a subtle detail lots of people get wrong: you should DELETE the key in the cache, not UPDATE the cache.

The reason is ordering. If two write requests happen almost simultaneously, the order in which they overwrite the cache can flip: the slower request (carrying the old value) writes to the cache after the faster request (carrying the new value), leaving the cache holding the old value even though the database already has the new one — and it sits there forever. But if you only delete, the next read always rebuilds the truth from the DB. Deletion is a self-healing operation: no “wrong value stuck in cache,” the worst case is just one cache miss.

The price: every write costs you an extra cache miss on the next read. Dirt cheap compared to holding wrong data. (This is also exactly how Facebook did it in the “Scaling Memcache” paper — they invalidate rather than update, for this very order-flipping reason.)

TTL: the net I once thought was redundant

A lesson I used to underrate: TTL is mandatory, even when you actively delete the cache on every write.

Why? Because “delete the cache on change” relies on an event — and events can be missed, can be buggy, can get swallowed somewhere. If one delete slips through, your cache goes stale forever. TTL is the last safety net: even when things go wrong, they’re only wrong for a few seconds or minutes before self-correcting, never wrong forever. I like to think of it this way: invalidation is the fast lane to freshness, and TTL is the harness that keeps you from ever being permanently wrong.

The trio that crushes a database

Then come the three classic problems I never knew the names of back then, but had in fact run into out in production. All three share the same ending: the cache can’t absorb it, and traffic slams straight into the DB.

The hardest question: delete cache first or write DB first?

But the part I’m proudest of, and also the hardest, is the consistency between cache and database. The question sounds simple: when updating data, should you write the DB then delete the cache, or delete the cache then write the DB?

I used to think deleting the cache first was safer — if the DB write fails, at worst you’ve cost yourself one cache miss. But that’s only half the story. The more important half is what happens with two concurrent requests.

The window between “delete cache” and “finish writing the DB” is fairly wide, and a read request slipping in right then will read the old value and reload it back into the cache. Conversely, if you write the DB first then delete the cache, the stale window is much narrower — because a write is usually slower than a read, so the gap for a reader to squeeze in and read-then-reload nearly closes. That’s why the industry’s standard recommendation is write the DB first, delete the cache after, even though at first it sounds counterintuitive.

And even with the right order, a small gap remains. To patch it thoroughly, people stack multiple layers:

• TTL as the baseline — the safety harness, mentioned above.
• Delayed double delete — delete the cache, write the DB, wait a moment, then delete the cache again, to sweep out the old value a read request may have managed to reload during the write.
• Retry queue — if the cache delete fails (Redis blinks for a second), don’t ignore it; push it onto a queue to retry until it succeeds.
• CDC — the most advanced: read the database’s binlog/WAL with a tool like Debezium, so whenever the DB actually changes it automatically emits a signal to delete the cache. No misses, and fully decoupled from the business code.

The lightbulb moment: it’s the Dual Write Problem

Here I had a moment where I froze: the “write DB then delete cache” problem is actually the very Dual Write Problem I once ran into working with message queues. Again it’s writing to two systems (the DB and the cache) with no shared transaction — identical to writing the DB then publishing an event to a broker.

When you recognize the same problem hiding under many different shells, I felt myself starting to think more like an architect — less rote-memorizing each pattern, and starting to see the common frame behind them.

Not all data should be cached the same way

Another lesson, about how to think rather than about technique: not all data should be cached the same way.

• Product name, description, images — practically never change. Cache with a long TTL, no worries.
• Price — changes now and then. Cache moderately, and delete on change.
• Inventory — changes constantly and needs to be accurate. This is where you have to be most careful.

For inventory, I split it into two levels. The number shown on a listing screen doesn’t need to be perfectly accurate — cache it with a few-second TTL, accept a little staleness, nobody dies over it. But when the customer clicks to place the order and actually decrements stock, you ABSOLUTELY do not decide based on the cache — you go straight to the source of truth with an atomic operation, because overselling is an error that isn’t allowed to happen.

The price: the cache is for speeding up reads, not for deciding business logic that has to be exact to the unit. Knowing where you’re allowed to be a little wrong, and where you absolutely aren’t, is the hard part.

Redis isn’t a key-value store — it’s a data structure server

I want to give this its own section, because a lot of people (me, back in the day, included) treat Redis as just a fast key-value store. It’s really a data structure server — the value is a typed data structure, not a blind blob.

• Hash — store an object field by field, so you can update exactly one inventory field without rewriting the whole object.
• Sorted Set — build leaderboards, rate limiters, priority queues (members ordered by score).
• HyperLogLog — approximate unique counting, error of only ~0.81%, each key costing at most ~12 KB while counting up to 2⁶⁴ elements. Count billions of unique visitors for a dozen-odd KB.
• Bitmap — ultra-compact binary flags (active users per day, feature flags).
• Geo — search by radius, “the place nearest me.”
• Stream — an append-only log with consumer groups, for a proper queue with acks.

Knowing how to pick the right structure for the right problem is half of Redis’s power. The other half lies in understanding how it works inside.

A few things about Redis worth grasping deeply

Eviction policy. When RAM fills up, Redis has to decide which key to delete. You should distinguish LRU (evict what hasn’t been used in the longest) from LFU (evict what’s used least frequently) depending on your access pattern. A nice detail: Redis doesn’t track LRU/LFU exactly per key (too much memory), it randomly samples a handful of keys and picks a victim — approximate, good enough, and cheap.

Single-thread. Redis processes commands on a single thread — that’s why it’s fast, and also why you absolutely avoid heavy commands like KEYS in production (it scans the whole keyspace, hard-locks the server; use SCAN to walk by cursor). But that single-threaded nature turns into a superpower when you need atomicity: wrap a chunk of logic in a Lua script, and Redis runs the whole thing without letting any command wedge in between. That’s how a rate limiter or stock decrement can fend off race conditions across thousands of servers — “check stock then decrement” fused into one indivisible step.

Durability. Redis has RDB (snapshotting — compact, fast to restore, but you lose the data between two snapshots) and AOF (logs every command — more durable, usually fsync every second so you lose at most ~1 second, but heavier). Production usually enables both.

Scale. When a single Redis can’t carry the load: replication to scale reads, Sentinel to auto-failover when the master dies, and Cluster to shard data across many nodes (split into 16,384 hash slots, keys hash into a slot, slots spread across the nodes).

Caching is never free

Sitting down to write all this out, I realized the most important thing isn’t any individual technique, but the way of seeing. The DB-crushing trio, the cache-delete ordering, delayed double delete, CDC — all of them are lines of debt born from one initial decision: “add a Redis to make it fast.”

Phil Karlton was right: invalidation is one of the two hardest things. But hard doesn’t mean dodge it. Hard means you have to see the price before you sign the invoice — not throw Redis in and wait for production to mail you the bill later, like the me of a few years ago.