Redis vs Memcached

1The Question This Topic Actually Answers

Both tools solve "keep hot data in RAM so I don't hit the database every request." The interesting question isn't "which is faster" (for a plain get/set of a small string, both are sub-millisecond and the difference is noise) — it's which mechanical design decisions each one made, and which real workloads those decisions favor. 01-redis/cache_redis_theory.md and 02-memcached/cache_memcached_theory.md each cover one side in depth; this file is the head-to-head.

2Side-by-Side

3Choosing Based on the Actual Workload

Favor Memcached when:

• The workload is purely simple key -> flat-blob caching (rendered HTML fragments, serialized API responses) with no need for server-side structure operations.
• You want to maximize raw throughput per box for that narrow workload by using every CPU core in one process.
• You explicitly do NOT want persistence — an empty-on-restart cache is a correctness feature here, not a gap, because you never want stale-but-durable data surviving a deploy.

Favor Redis when:

• You need atomic operations on structured data server-side (increment one hash field, push onto a capped list, maintain a leaderboard) without round-tripping the whole blob to the client.
• You want the cache to survive a restart without a full cold-cache thundering herd (see 05-cache_invalidation/cache_cache_invalidation_theory.md), via RDB/AOF.
• You need pub/sub, streams, rate-limiting primitives, distributed locks (SETNX/SET ... NX), or geo commands — none of which have a Memcached equivalent.
• You want built-in replication/clustering rather than building your own client-side sharding layer.

4What They Genuinely Share

Both are volatile-by-assumption caches sitting in front of a slower source of truth; both expect the application to handle cache misses by querying that source of truth (this is the cache-aside pattern covered fully in 06-cache_aside_write_through_write_behind/); both rely on TTL for automatic staleness bounding (07-ttl/); and both, at multi-node scale, depend on consistent hashing to route a given key to a specific node predictably (08-distributed_caching/).

Under the HoodWhy the Architectures Diverged, Mechanically▾

This is the crux, not a footnote. Memcached's single-type, no-persistence, no-replication design is not an earlier, less mature version of what Redis became — it is a deliberately narrower system, and the narrowness is what buys its concurrency model.

Because a Memcached value is an opaque blob with exactly one operation shape ("replace these bytes" / "read these bytes," plus incr/decr for the special case of a numeric string), multiple threads can service unrelated keys with only fine-grained per-bucket locking — there is no cross-key invariant a lock has to protect beyond "don't corrupt this one hash bucket while it's being mutated." A get key1 and a set key2 can execute genuinely concurrently on different cores with only brief mutual exclusion, if any, on the shared structures they each touch.

Redis's data model breaks that independence. A single logical operation like ZADD has to correctly update a sorted set's dual backing structure (skip list and hash table, kept consistent with each other) as one atomic step, and richer future commands can combine multiple keys (SINTERSTORE, MULTI/EXEC blocks touching several keys) with a correctness requirement that nothing else runs in between. Redis's authors chose to buy that correctness for free — no lock design, no risk of forgetting a lock, no lock contention overhead — by making the entire command execution path single-threaded, accepting the throughput ceiling of one core for command execution in exchange. Memcached's authors chose to buy raw multi-core throughput by keeping the data model simple enough that locking could stay cheap and local.

Neither choice is a mistake the other project corrected; they are two different answers to the same trade-off (concurrency-model complexity vs. data-model richness), each internally consistent with what the tool is for.

⚠️ Common Pitfalls

1. Assuming one is a strict upgrade of the other — picking Redis "because it can do more" for a workload that's genuinely just flat-blob caching adds operational complexity (persistence config, richer failure modes) for no benefit.
2. Running Memcached but architecting as if it persists — after any restart/crash/OOM-kill, the cache is empty; code paths must tolerate a 100% cache-miss cold start.
3. Running single-instance Redis and expecting Memcached-like multi-core throughput — a single Redis process caps command execution at one core; horizontal scaling requires Redis Cluster or multiple instances, not just "more Redis on the same box."
4. Comparing raw benchmark numbers out of context — for trivial get/set of small values, both are sub-millisecond; meaningful differences only show up under specific access patterns (many small independent keys favoring Memcached's parallelism, or compound structured operations favoring Redis's atomics).
5. Forgetting Memcached has no selectable eviction policy — if you need volatile-ttl or allkeys-lfu semantics, that requirement alone rules out Memcached.

📋 Quick Reference

                  Redis                          Memcached
Data types        strings, hash, list, set,      strings only (opaque bytes)
                  zset, stream
Concurrency       single-threaded event loop      thread pool + fine-grained locks
Persistence       RDB and/or AOF                  none
Replication       built-in (Sentinel/Cluster)      none (client-side sharding only)
Eviction          selectable policy                fixed strict LRU per slab class
Best for          structured ops, durability,      pure flat-blob caching,
                  pub/sub, rate limiting            max per-box throughput

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: cache_redis_vs_memcached_theory.md · generated by tools/build_lessons.py