"Redis vs Memcached"
Choosing an in-memory store: Redis and Memcached compared on data structures, threading, persistence, replication, clustering, eviction, memory efficiency and operations, with guidance on when a plain cache is enough and when you need Redis features.
Reading is half of it. See this used in a real interview: walk through Design a Distributed Cache →
Both Redis and Memcached keep data in memory and answer in well under a millisecond, and both appear in designs as "the cache". They are not interchangeable: Memcached is a deliberately simple, multithreaded key-value cache, while Redis is a single-threaded-at-its-core server of data structures with persistence and replication. Interviewers occasionally ask which you would choose; the answer depends on whether you need more than get and set.
Memcached
- Strings only: keys map to opaque byte values, up to 1 MB by default.
- Multithreaded: uses all cores on a large machine efficiently.
- No persistence and no replication: a restarted node is empty; data loss is expected.
- Client-side sharding: clients hash keys to servers (usually with consistent hashing); servers do not know about each other. See consistent hashing.
- Slab allocator with LRU eviction per slab class: predictable memory, little fragmentation.
- Very simple to run.
Facebook famously scaled Memcached to enormous fleets for look-aside caching of database queries.
Redis
- Rich data structures: hashes, lists, sets, sorted sets, streams, HyperLogLog, geo indexes, bitmaps. See Redis data structures.
- Server-side operations: increments, rank queries, set intersections and Lua scripts execute atomically in the server.
- Persistence: snapshots and append-only logs.
- Replication to replicas with automatic failover (Sentinel or Cluster).
- Redis Cluster shards keys across nodes with hash slots.
- Pub/sub and streams for messaging.
- Command execution is single-threaded per instance (with I/O threads in newer versions), so you scale by running more shards. Forks (Valkey) and compatible alternatives (KeyDB, Dragonfly) exist, some multithreaded.
Comparison
| Memcached | Redis | |
|---|---|---|
| Data model | strings | many data structures |
| Atomic server-side logic | increment, compare-and-set | many commands plus Lua scripts |
| Threading | multithreaded | single-threaded command execution per shard |
| Persistence | none | snapshots, append-only log |
| Replication and failover | none built in | built in |
| Sharding | client-side | Redis Cluster or client-side |
| Memory efficiency for small strings | very good | good, more per-key overhead |
| Use beyond caching | no | leaderboards, rate limiters, queues, sessions, locks |
| Operations | simplest | more features, more to configure |
When Memcached is enough
- A pure look-aside cache of database rows, rendered fragments or API responses.
- Values are blobs you get and set whole.
- Losing the cache is acceptable (it refills from the database).
- You want maximum throughput per machine with minimal operations.
See caching.
When you need Redis
- Leaderboards with sorted sets. See Design a Leaderboard.
- Rate limiters with atomic scripts. See Design a Rate Limiter.
- Capped timelines and feeds with lists or sorted sets. See Design a News Feed.
- Sessions that should survive restarts, with replication.
- Counters, unique counts, geospatial queries, delayed queues and pub/sub.
- Any case where you would otherwise read, modify and write back a blob from many servers concurrently.
Shared concerns
Both need the same caching discipline:
- TTL and eviction policy chosen deliberately (LRU or LFU), with memory sized for the working set.
- Stampede protection for hot keys that expire: request coalescing, early refresh, jittered TTLs.
- Hot keys that overload one shard: local caching or replicated keys. See hot keys and skew.
- Invalidation on writes. See cache invalidation.
- Neither is a database of record for data you cannot lose, even with Redis persistence.
In the interview
"We use Redis because we need sorted sets for the leaderboard and atomic counters, with replicas for failover; data can be rebuilt from the database if lost." Or, for a pure cache: "Memcached or Redis both work; it is a look-aside cache of rendered results with TTLs, sharded with consistent hashing." For Design a Distributed Cache, explain the internals either way: hashing, eviction, replication choices and hot-key handling.
Checklist
- Memcached for simple, high-throughput, loss-tolerant caching.
- Redis when you need data structures, atomic server-side logic, persistence or replication.
- Eviction, TTLs and memory sized to the working set.
- Stampede and hot-key protection.
- The database remains the source of truth.