Skip to content

Redis vs Memcached (Caching Focus)

1. Decision

Choose Memcached as a pure caching solution for high-throughput, multi-threaded, simple key-value string workloads; choose Redis when caching requires complex data structures (Lists, Sets, Hashes, Sorted Sets), high availability failover (Sentinel), replication, persistence, or atomic Lua scripts.

2. 30-Second Answer

When evaluating Redis vs Memcached strictly as application cache layers, both deliver sub-millisecond in-memory read/write performance. Memcached excels at high-concurrency multi-threaded string caching on large multi-core servers, utilizing fixed-size Slab Allocation to eliminate OS memory fragmentation. Redis operates on a single-threaded event loop per process, but provides advanced caching features: server-side data structure manipulation (HSET, ZADD), atomic operations, key eviction policies (LRU, LFU), persistence (RDB/AOF), primary-replica replication, and automated high availability (Redis Sentinel/Cluster). For simple string caching at scale, Memcached is lighter; for rich dynamic application state caching, Redis is superior.

3. Decision Matrix

Option Best For Avoid When Latency Scalability Consistency Operational Complexity
Memcached Simple key-value string/blob caching, multi-threaded CPU scale-up, static HTML fragments Complex data structure caching, data persistence, automated failover requirements Sub-millisecond (<1ms) Vertical multi-threaded scale-up; Horizontal via client-side consistent hashing Ephemeral; No built-in replication across nodes Very Low
Redis Rich data structures, session state, rate limiting, leaderboards, HA replication, Sentinel Pure simple string caching on multi-core single instances without multi-process clustering Sub-millisecond (<1ms) Vertical RAM; Horizontal via Redis Cluster (Hash Slots) Primary-Replica async replication; Configurable persistence Medium

4. Selection Rules

Requirement Best Choice Rationale / Example
Multi-Core Single Machine CPU Saturation Memcached Multi-threaded memory architecture processes >1M QPS per node natively
Cache Invalidation by Hash Fields Redis Use Redis Hashes (HSET/HDEL) to invalidate individual fields without clearing entire object
Slab Allocation Memory Efficiency Memcached Fixed-size memory slabs prevent OS memory fragmentation under high key churn
Sorted Leaderboards & Top-K Caching Redis Sorted Sets (ZADD, ZREVRANGE) execute rank caching in \(O(\log N)\) complexity
Automated Cache Node Failover (HA) Redis Redis Sentinel promotes replicas to primary automatically upon node death
Atomic Cache Increments with Expiration Redis INCR + EXPIRE combined in single atomic operation or Lua script

5. Tradeoffs

  1. Multi-Threaded Hardware Utilization vs Single-Threaded Event Loop
  2. Gain (Memcached): Scales linearly across 32+ CPU cores on a single large cache instance.
  3. Lose (Memcached): Lacks rich server-side computation or data structures.
  4. Data Structure Versatility vs Pure String Caching
  5. Gain (Redis): Update nested cached object attributes (HSET) without re-serializing entire JSON string.
  6. Lose (Redis): Consumes higher memory overhead per key due to redisObject metadata headers.
  7. Slab Allocator Determinism vs jemalloc Dynamic Allocation
  8. Gain (Memcached): Zero OS memory fragmentation during continuous write/delete churn.
  9. Lose (Memcached): Wastes memory if cached payload sizes don't align closely with slab class sizes.
  10. Replication & Persistence Capabilities vs Ephemeral Memory Only
  11. Gain (Redis): Replicas prevent cold-cache database crashes during primary node restarts.
  12. Lose (Redis): Managing replication lag, split-brain Sentinel elections, and cluster hash slot rebalancing.
  13. Client Routing Simplicity vs Server-Managed Hash Slots
  14. Gain (Memcached): Client libraries (e.g., Ketama consistent hashing) route requests without server cluster gossip.
  15. Lose (Memcached): Client configuration drift causes cache key routing mismatches.

6. Interview Counter Questions

  1. How do eviction policies differ between Memcached (Slab LRU) and Redis (Global LRU / LFU)?
  2. How does Redis version 6.0+ multi-threaded I/O impact the performance gap with Memcached?
  3. Why does updating a nested JSON string in Memcached cause high network and CPU serialization overhead?
  4. How do you implement Cache Warming in Redis vs Memcached after a cluster reboot?
  5. What is the impact of Redis single-threaded blocking commands (KEYS *, FLUSHALL) in a production cache cluster?
  6. How does Memcached handle memory allocation via Slab Classes and what is Slab Calcification?
  7. Why is Redis preferred over Memcached for distributed rate limiting and sliding window counters?
  8. How does Redis Sentinel detect node failure and perform automatic master election?
  9. When would you deploy a proxy layer (Twemproxy / Mcrouter / Envoy) in front of Redis or Memcached?
  10. How do you handle cache memory fragmentation in Redis without restarting the process?

7. Gold Standard Answers

  1. Memcached applies LRU eviction strictly within individual slab classes; a full slab class evicts keys even if other slab classes have free memory. Redis evaluates global LRU/LFU approximations across the entire dataset.
  2. Redis 6.0 offloads network I/O socket reading/writing to background worker threads while keeping command execution strictly single-threaded, narrowing the raw throughput gap with Memcached while preserving atomicity.
  3. In Memcached, updating 1 field requires fetching the full JSON string over the network, deserializing it, mutating the field, re-serializing, and writing back. In Redis, HSET my_key field value updates the attribute directly in memory.
  4. Redis reloads memory state rapidly from RDB snapshots or AOF logs on boot. Memcached starts completely cold (empty RAM); warming requires executing synthetic background application queries before opening public traffic.
  5. Blocking \(O(N)\) operations stop the single-threaded event loop, queueing incoming client requests until socket timeouts trigger cascading application outages. Always use SCAN and UNLINK instead.
  6. Memcached allocates memory into fixed slab sizes (e.g., 64B, 128B). Slab Calcification occurs when slabs become locked to specific size classes based on historical traffic; if traffic patterns shift to different payload sizes, memory becomes underutilized.
  7. Redis supports native atomic data primitives (INCR, ZADD) and Lua scripts. Memcached only supports basic string incr, making complex sliding window rate limiters difficult to implement without race conditions.
  8. Sentinel instances monitor primary nodes via PING heartbeats. If a quorum of Sentinels reports SDOWN (subjective down), it escalates to ODOWN (objective down), triggering a Raft-like election to promote the best replica to primary.
  9. Deploy Twemproxy or Mcrouter to manage connection pooling, request multiplexing, and consistent hashing sharding across hundreds of cache nodes, saving backend application connection overhead.
  10. Redis includes an active defragmentation engine (activedefrag yes) that allocates new memory pages for live keys using jemalloc and frees fragmented pages transparently in the background without restarting.

8. Common Mistakes

  • Running KEYS * or synchronous DEL on large keys in production Redis, freezing the entire cache layer.
  • Using Memcached for objects requiring frequent partial updates, wasting serialization CPU and network bandwidth.
  • Relying on Memcached for critical session state without a persistent database backup or replication layer.
  • Over-allocating memory past physical RAM limits, triggering OS swap thrashing and destroying cache latencies.
  • Ignoring Redis memory fragmentation ratio (mem_fragmentation_ratio > 1.5), leading to out-of-memory crashes.

9. Keywords

Redis, Memcached, Eviction Policy, LRU, LFU, Slab Allocation, Slab Calcification, Active Defragmentation, Redis Sentinel, Twemproxy, Mcrouter, Redis 6.0 Multi-Threaded I/O, UNLINK, HSET.

10. Cheat Sheet

  • Core Metric: Pure multi-threaded string caching = Memcached; Rich data structures & HA caching = Redis.
  • Memory Management: Memcached = Slab allocation (no OS fragmentation, but risk of slab calcification); Redis = jemalloc + Active Defragmentation.
  • Data Mutation: Redis allows field-level updates (HSET); Memcached requires full string re-serialization.
  • Failover & HA: Redis Sentinel/Cluster provides auto-failover and replication; Memcached relies on client-side sharding or proxies (Mcrouter).
  • Eviction: Memcached = Per-slab LRU; Redis = Configurable global LRU, LFU, or random eviction.
  • Command Safety: Never run \(O(N)\) blocking commands (KEYS *, DEL) in Redis; use SCAN and UNLINK.

11. Related Decisions