Redis vs. Memcached: What Are We Really Getting?

By now, we've covered why caching improves performance, how caches work, where they can live, common caching patterns, and why invalidation is hard. Let's make things concrete.

When someone says "let's add a distributed cache," two names almost always come up: Redis and Memcached. Both are extremely fast, both store data primarily in memory, and both can dramatically reduce database load.

So the obvious question is which one to use. But the answer isn't "Redis is better" — that's too simplistic. The better question is: what problem are you trying to solve?

1. What is Memcached?

Memcached is essentially a high-performance distributed key-value cache. You give it a key, it gives you back a value:

user:123 → {name: "John", age: 42}

GET user:123

That's the basic idea, and Memcached keeps it deliberately simple. Its job is to store temporary data in memory and retrieve it very quickly. That simplicity is one of its biggest strengths.

2. What is Redis?

Redis also started as a fast in-memory key-value store, but it's evolved into something broader. It supports several data structures — strings, hashes, lists, sets, sorted sets, and streams — so instead of storing a flat JSON blob under user:123, you can store a structured hash with individual fields. Redis also gets used for counters, leaderboards, queues, distributed coordination, rate limiting, session storage, pub/sub, and event streams.

The simplest way to hold the distinction: Memcached says "I need a really fast temporary cache." Redis says "I need a really fast in-memory data platform that can also act as a cache." Memcached focuses on simplicity. Redis gives you significantly more capability — for a price we'll get to.

3. Redis can be more than a cache — and that's a warning too

Imagine your architecture starts simple: Redis as a cache. Then someone notices Redis can also handle session data, so it does. Then rate limiting gets added. Then someone wires up Redis Streams for events. Each step is individually reasonable.

Here's the architectural lesson: the more responsibilities you put into Redis, the less comfortable you should be treating it as disposable cache infrastructure. If Redis is only a cache, you can usually rebuild it. If it contains important state, losing it becomes a much more serious conversation.

4. Persistence

Redis can be configured with persistence so data survives a restart — useful once Redis is holding more than disposable cache entries. Memcached is much more cache-oriented: if the server restarts, you generally assume the cached data is gone, and that's fine as long as the architecture was designed with that assumption in mind. A cache should usually be rebuildable — persistence is what you reach for once something stops being "just a cache."

5. If Redis goes down, what happens?

This is a question every architect should ask before it happens in production, not after.

Ideally, Redis becoming unavailable means a clean fallback: cache miss, go to the database. But if Redis normally absorbs 99% of traffic and it suddenly disappears, all of that traffic lands on the database at once — overload, slow responses, timeouts, and the application degrading along with it.

Redis isn't dangerous because it's slow. It's dangerous because it's so effective at absorbing traffic that the rest of the system may never have been tested without it. We'll dig into this failure mode properly in the next part of this series.

6. Scaling

Both Redis and Memcached scale horizontally, but the shape differs. Memcached typically uses a straightforward distributed model — keys spread across nodes with a simple hashing scheme. Redis also supports clustering, but Redis clustering brings additional considerations: partitioning, replication, failover, topology, and resharding.

The lesson isn't that one scales and the other doesn't — both do. The real question is how much operational complexity you're willing to take on.

7. Performance

You'll hear "Redis is faster" and "Memcached is faster" from different people, and in practice, both can be extremely fast for a basic GET/SET. For most applications the difference won't matter — your actual bottleneck is more likely to be the network, serialization, application processing, connection pooling, or the database itself.

Don't pick a caching technology off a microbenchmark. Ask instead: does it meet my application's actual latency and throughput requirements?

8. Memory efficiency and eviction

Memcached's simplicity gives it relatively straightforward memory management, which matters if you're storing millions of tiny objects and every byte counts. Redis's richer data structures can carry more memory overhead depending on which ones you use. The right answer depends on key size, value size, entry count, structure choice, and metadata overhead — measure your actual workload rather than assuming.

Both support eviction policies (Redis offers LRU, LFU, TTL-based, and no-eviction configurations; Memcached has its own caching-oriented mechanism). We covered why eviction matters back in Part 2 — the architectural lesson there still applies: know what happens when your cache runs out of memory before production finds out for you.

9. Where Redis pulls ahead: counters, rate limiting, leaderboards

A few examples where Redis's extra structure earns its complexity. For rate limiting, an atomic counter per user makes a request-per-minute limit straightforward to implement correctly under concurrency — something Memcached can approximate but wasn't built around. For leaderboards, Redis Sorted Sets are purpose-built for maintaining and efficiently querying ranked data; Memcached's flat key-value model isn't designed for that kind of query at all.

These aren't caching problems in the traditional sense — they're state problems that happen to want the same speed a cache provides.

10. When Memcached makes perfect sense

Redis gets most of the attention, but that doesn't make Memcached obsolete. If your requirements are simple key-value caching, temporary data, a large number of entries, straightforward scaling, no need for rich data structures, and a cache that can be completely rebuilt from scratch — Memcached's simplicity is a feature, not a limitation. If all you need is GET, SET, and DELETE, there's no reason to carry the operational weight of streams, sorted sets, pub/sub, and persistence you'll never use.

11. A practical comparison

Don't turn this into a checklist exercise — the right choice depends on your workload, not on how many rows favor one column.

12. A real-world decision

Say you're designing a simple product catalog service: GET product:123, returning a small JSON object that changes occasionally. No queues, no streams, no leaderboards, no counters, no persistence requirement. Either Redis or Memcached would work fine here — there's no reason to reach for Redis just because it has more features sitting unused.

Now imagine the same platform also needs rate limiting, session storage, counters, leaderboards, and some distributed coordination. Redis becomes much more compelling, because now you actually need the capabilities it provides beyond caching.

13. Don't ask "which is better?"

This is the biggest lesson in this comparison. Don't ask "Redis vs. Memcached, which is better?" Ask what capabilities does my system actually need? A simple cache points toward Memcached being enough. A richer in-memory platform points toward Redis being the better fit. And sometimes the honest answer is neither — a managed cloud caching service, a CDN, a database-level cache, or an application-local cache might solve the actual problem better.

Technology should follow the requirement, not the other way around.

14. The architect's checklist

Six questions worth running through before committing to either: What's the data model — plain key-value, or something richer? What's the durability requirement — can this data simply disappear, or does it need a persistence strategy? What's the availability story — what happens to the application when the cache is unreachable? What's the expected scale — keys, requests per second, total data size? Who owns the operational complexity — monitoring, patching, scaling, recovery, troubleshooting? And most importantly, what's the failure behavior — what does the application actually do when the cache is gone?

That last question usually matters more than which cache wins a benchmark.

The bigger lesson

Redis and Memcached are both excellent technologies, and the interesting difference isn't "newer vs. older" or "better vs. worse." It's focused caching vs. caching plus a broader in-memory toolbox — and there's a wider principle underneath that distinction: don't introduce complexity unless you actually need the capability that comes with it. A simple cache that does exactly what you need can beat a powerful platform your team doesn't need yet.

What's next

We've now covered why caching exists, how it works, where it lives, the patterns for using it, how to keep it honest, and two of the most common technologies that implement it.

But we still haven't answered the question this post kept circling back to: what actually happens to your system when the cache goes down? That's next.

If you've run both in production, what tipped the decision for you — was it the data model, or was it really about who was going to operate it at 2am?