Redis vs Memcached

Both are in-memory key-value stores with sub-millisecond reads, both sit in front of a database, and both appear in every "add a cache" answer. They are built on opposite philosophies. Memcached is a deliberately dumb, multi-threaded, volatile cache: strings in, strings out, evict whatever is least recently used, no persistence, no replication, no opinions. Redis (and its open-source fork Valkey) is an in-memory data structure server: sorted sets, hashes, streams, atomic scripts, replication, optional persistence — a cache that can also be a leaderboard, a rate limiter, a lock service and a queue. The question that decides it: is this purely a cache of values you can recompute from somewhere else, or does the data structure or the data itself matter? If it is purely a cache and the fleet is large, Memcached's simplicity is a feature. If you need anything beyond get/set — or you will within a year — Redis.

Go deeper:

• The miss path in depth (leases, gutter pools, routing tiers and the arithmetic of a miss storm when a node dies) is in Memcached.

The Verdict#

Default to Redis (or Valkey) — it does everything Memcached does well enough and many things Memcached cannot. Pick Memcached for very large, pure look-aside caches where multi-threaded throughput per node and operational simplicity matter more than features.

🎯 Staff Move: "For a pure look-aside cache either works, so I'll pick Redis — or Valkey on the managed service — because the next three asks from product will be a rate limiter, a leaderboard and a session store, and I'd rather run one caching technology than two. If we were at hundreds of cache nodes doing nothing but get and set, I'd revisit Memcached for cost per GB and cores per node."

At a Glance#

Redis or Valkey? For design purposes they are the same engine family; the choice is licensing and vendor, not architecture.

How They Actually Differ#

Data Structures: The Cache That Became a Database#

Memcached stores bytes. To add an item to a cached list you read the whole list, deserialize, append, serialize and write it back — with cas to avoid losing a concurrent update. Redis does it server-side in one atomic command.

The same "append to a user's recent-items list, keep 50" in each:

Memcached (client does the work, retries on conflict):
  loop up to 5 times:
      value, cas_token = gets("recent:42")
      items = deserialize(value) or []
      items = [new_item] + items[:49]
      if cas("recent:42", serialize(items), cas_token, ttl=3600) == STORED: break
      # NOT_STORED/EXISTS → someone else wrote first; retry
  # under contention on a hot key, retries pile up and some updates are dropped

Redis (server does the work, atomically, one round trip):
  MULTI
    LPUSH recent:42 new_item
    LTRIM recent:42 0 49
    EXPIRE recent:42 3600
  EXEC

Who pays: with Memcached the application team pays for every data-structure feature in serialization code and CAS retry loops. With Redis the on-call pays when someone runs ZRANGE over 10 million members or KEYS * on the main thread and blocks every other client.

Threading: One Fast Core vs All the Cores#

Redis executes commands on a single main thread per process. That is why every command is atomic without locks, and why one slow command (a large DEL, an unbounded LRANGE, a heavy Lua script) stalls every client on that shard. Network I/O can be spread over threads, and Valkey 8 made that substantially more effective, but data access stays single-threaded. To use 16 cores you run many shards.

Memcached is multi-threaded across a shared hash table with fine-grained locking. One process on a 32-core box uses all 32 cores for one cache. Fewer, bigger nodes; fewer things to route to.

Who pays: a Redis fleet has more processes to monitor and fail over; a Memcached fleet has fewer, larger blast radii per node.

Durability and Replication#

Memcached has none, on purpose. A node restart is a cold cache for its slice of keys; a node loss sends that slice of traffic to the database. Large operators handle this with redundant pools or regional replicas built in the client or a proxy layer.

Redis offers asynchronous replication with automatic failover (Sentinel, Cluster or the managed service), plus optional persistence. Replication is async, so a failover can lose the last few hundred milliseconds of writes — fine for a cache, worth stating for a session store or a rate limiter.

🎯 Staff Insight: "Redis has persistence" does not make it a system of record. AOF with fsync every second can lose a second of writes, async replication can lose more on failover, and recovery time grows with dataset size. If the data must not be lost, it belongs in a database with Redis in front.

Memory Efficiency and Eviction#

Both pay per-key overhead (tens of bytes) on top of the value. Memcached's slab allocator groups items by size class; if the item size distribution shifts, memory gets stuck in the wrong slab class until it is rebalanced (modern versions do this automatically). Redis allocates per object with jemalloc; fragmentation after heavy churn can leave resident memory well above the dataset size (mem_fragmentation_ratio > 1.5 is a warning sign).

Redis's compact encodings for small hashes, sets and sorted sets can store many small values far more densely than one key per value — a well-known trick for large maps of small IDs. Memcached has no equivalent; one key, one item.

Eviction differs in control: Redis lets you choose the policy — and noeviction turns it into an error-returning store when full, which is the right setting for data you must not silently drop and the wrong one for a cache. Memcached always evicts by LRU within the slab class.

Scaling Out: Who Knows Where a Key Lives#

Memcached servers do not know about each other. The client hashes the key onto a ring of servers (consistent hashing, so adding a node remaps ~1/N of keys). Proxies (for example mcrouter at Facebook scale) add pools, replication and failover outside the servers.

Redis Cluster puts the routing in the protocol: 16,384 hash slots assigned to primaries; clients cache the slot map and follow MOVED redirects; resharding moves slots online. Multi-key commands work only when all keys share a slot ({user:42}:cart, {user:42}:profile via hash tags).

Where Each One Breaks#

Redis / Valkey#

Memcached#

One Cache Node Dies at Peak#

Ten nodes, 500K reads/s, 95% hit rate, database sized for 40K reads/s.

                 Memcached (10 nodes, no replicas)              Redis (10 primaries + replicas)
t=0              node 7 dies                                    primary 7 dies
t=+1s            10% of keys now miss → +50K DB reads/s         clients get errors / timeouts for slot range
                 DB at 75K reads/s (sized for 40K)              of shard 7 (10% of keys)
t=+5s            DB p99 10ms → 400ms; app threads pile up       replica promoted (managed failover:
                 on slow queries                                ~seconds to tens of seconds)
t=+30s           client ring removes node 7 → its keys          shard 7 serving again from replica's data,
                 rehash to 9 nodes, all cold → still missing    hit rate back to ~95%
t=+10min         hit rate recovers as keys refill               replacement replica syncing in background
Mitigation       request coalescing on miss, stale-while-       client retry with short timeout,
                 revalidate, DB headroom, a second pool         replicas in another AZ

Who pays: with Memcached the database team absorbs the incident; with Redis the cache budget paid for it in advance with replicas. Neither is wrong — but the choice must be explicit, and the database owner must have signed off on the Memcached version.

The production surprise for both: the cache becomes load-bearing. Once the database is sized for a 95% hit rate, a cold cache is an outage, not a slowdown. Both need a warm-up plan and request coalescing on miss.

Cost and Operations#

Sizing example. 200 GB of cached objects, 500K reads/s at peak:

Memcached:  4 × 64 GB nodes (with headroom), no replicas      ≈ 256 GB of memory paid for
            each node ~125K ops/s — well within one multi-core node
            lose a node → 25% of keys miss → DB must handle ~125K extra reads/s briefly

Redis:      8 shards × 32 GB + 1 replica each                 ≈ 512 GB of memory paid for
            ~62K ops/s per shard — comfortable on one core
            lose a primary → replica promoted in seconds, no miss storm

The Memcached fleet is roughly half the memory bill. The Redis fleet buys failover without a miss storm. Who pays is the choice: the cache budget, or the database during an incident.

🧭 Principal Insight: "Memcached is cheaper per cached gigabyte; Redis is cheaper per feature. At most companies the feature count wins because every team that needs a counter or a lock would otherwise build one. At a handful of very large companies the gigabyte wins, and they run both."

Switching Later#

One-way doors: using Redis as the system of record (every feature built on it assumes its semantics); hash-tag schemes that pin related keys to one slot. Two-way doors: engine choice for a pure cache, eviction policy, node size, number of shards.

How Real Companies Chose#

Facebook: Memcached as a Planet-Scale Cache#

Facebook's NSDI 2013 paper describes turning memcached into a distributed cache tier that handles billions of requests per second and holds trillions of items for over a billion users, accepting imprecise semantics — eviction, data loss, no transactions — in exchange for performance and simplicity, and putting the intelligence (consistency with the database, failover, regional replication) around the servers rather than in them (USENIX NSDI '13).

Staff insight: At that scale the server's simplicity is the point. Every feature in the cache process is multiplied by thousands of machines; Facebook moved the hard parts into clients and proxies they controlled.

Netflix: EVCache, Built on Memcached#

Netflix's EVCache is an open-source caching solution built on memcached and the spymemcached client, designed for AWS; the name stands for Ephemeral, Volatile Cache — data persists only for its TTL and can be evicted at any time (Netflix EVCache on GitHub).

Staff insight: Netflix chose a volatile engine and designed the system around that volatility — the name is a contract with every client team: don't store anything here you can't lose.

GitHub: Moving Persistent Data Out of Redis#

GitHub described disabling Redis persistence and moving data that had been stored durably in Redis — configuration, counters, rate-limit data, spam signals and activity feeds — into a MySQL-backed key-value store, citing operational cost and the team's deeper MySQL expertise. Activity feeds alone accounted for about 67% of over 350 million daily Redis writes before the migration cut write volume (GitHub Blog).

Staff insight: Redis's features invite teams to use it as a database. The bill arrives later as persistence operations nobody planned for. Decide early which Redis clusters are caches and which are stores, and staff them differently.

Follow-Ups to Expect#

What to Say in the Interview#

"For a pure look-aside cache both work. I'll use Redis — or Valkey on the managed service — because the same cluster type will serve the rate limiter and the leaderboard, and running one technology is cheaper than running two."

"This cluster is a cache, not a store: allkeys-LRU, no persistence, and the database is sized to survive losing one shard's worth of hits for a few minutes."

"The rate-limit counters are different — losing them on failover means a burst gets through, which product has signed off on — so they get replicas but still no persistence."

"If we were running hundreds of nodes of nothing but get and set, I'd look at Memcached seriously: multi-threaded nodes and no replicas roughly halve the memory bill."

Related Guides#

• Redis — data structures, Cluster, persistence and the operational detail
• Design a Distributed Cache — building the cache tier end to end
• Caching Basics — look-aside, write-through, invalidation, TTLs
• Read-Heavy Systems — where the cache sits among replicas and CDNs
• Hot Keys — the failure mode both engines share
• Hash Rings — how client-side sharding spreads keys
• Design a Rate Limiter — a classic Redis-shaped workload
• Design a Leaderboard — sorted sets in production