Skip to content

Redis vs Memcached

1. Decision

Choose Memcached for simple, multi-threaded, horizontal scale-out caching of static objects/HTML fragments where memory efficiency and simple key-value lookups dominate; choose Redis when complex data structures, in-memory persistence, replication/high availability, geospatial indexing, pub/sub, or atomic Lua scripts are required.

2. 30-Second Answer

Both Redis and Memcached are high-performance in-memory key-value caching stores operating with sub-millisecond latencies. Memcached is a lightweight, multithreaded key-value store optimized for high-throughput string/blob caching that scales efficiently across multiple CPU cores on a single machine using slab allocation to prevent memory fragmentation. Redis is a feature-rich, single-threaded (with multithreaded I/O helpers in v6+) data structure server offering rich data types (Hashes, Sets, Sorted Sets, Streams), disk persistence (RDB/AOF), master-replica replication, sentinel failover, and Redis Cluster. Select Memcached for simple distributed string caching; select Redis for advanced caching, real-time counters, leaderboards, or state management.

3. Decision Matrix

Option Best For Avoid When Latency Scalability Consistency Operational Complexity
Memcached Simple key-value string caching, static HTML page fragments, multi-threaded CPU saturation Complex data manipulation, persistence requirement, high-availability failover Sub-millisecond (<1ms) Horizontal via client-side consistent hashing; Vertical multi-threaded scale Ephemeral key-value; No replication across nodes Very Low
Redis Rich data structures, rate limiting, leaderboards, pub/sub, state persistence, Sentinel HA Pure simple key-value string caching on massive multi-core single instances Sub-millisecond (<1ms) Vertical RAM; Horizontal via Redis Cluster (Hash Slots) Primary-Replica async replication; Configurable persistence Medium (Cluster/Sentinel)

4. Selection Rules

Requirement Best Choice Rationale / Example
Multi-Core Single Instance CPU Saturation Memcached Native multithreaded memory architecture handles >1M QPS per node
Rich In-Memory Data Structures Redis Native Hashes, Sets, Sorted Sets (ZSET), Bitmaps, HyperLogLogs
In-Memory Data Persistence (Snapshots/Logs) Redis RDB snapshots and Append-Only File (AOF) persist state to disk
High Availability & Instant Failover Redis Redis Sentinel provides automatic master election and VIP failover
Memcached Slab Allocation Memory Optimization Memcached Fixed-size memory slabs prevent OS memory fragmentation for fixed objects
Atomic Multi-Operation Lua Scripts Redis Server-side Lua execution eliminates application-level network roundtrips

5. Tradeoffs

  1. Multi-Threaded Simplicity vs Single-Threaded Event Loop
  2. Gain (Memcached): Scale performance vertically by adding CPU cores on a single box.
  3. Lose (Memcached): Lack of advanced data structures or server-side computation.
  4. Data Structure Versatility vs Pure Key-Value Simplicity
  5. Gain (Redis): Perform operations directly in memory (e.g., SADD, ZINCRBY) without full object serialization.
  6. Lose (Redis): Higher memory overhead per key payload due to rich internal data structures (robj metadata).
  7. Slab Allocator Memory Management vs jemalloc Eviction
  8. Gain (Memcached): Memory allocation is deterministic, eliminating OS-level memory fragmentation.
  9. Lose (Memcached): Waste memory if object sizes don't align with slab size classes.
  10. Replication & Persistence Capabilities vs Ephemeral Cache Only
  11. Gain (Redis): Replicas maintain cache state during primary node replacement.
  12. Lose (Redis): Increased operational complexity managing Sentinel/Cluster state machine transitions.
  13. Client-Side Sharding vs Native Cluster Sharding
  14. Gain (Memcached): Simple client-side consistent hashing ring (Libmemcached) without cluster coordination overhead.
  15. Lose (Memcached): Adding/removing nodes requires client ring re-configuration.

6. Interview Counter Questions

  1. How does Memcached's multi-threaded architecture compare to Redis single-threaded event loop?
  2. What is Memcached Slab Allocation and how does it prevent memory fragmentation?
  3. How does Redis version 6.0+ utilize multi-threading without breaking single-threaded command execution?
  4. How do client-side consistent hashing rings work in Memcached vs Redis Cluster Hash Slots?
  5. Why would Facebook create Memcached extensions (Mcrouter) instead of migrating entirely to Redis?
  6. How does key eviction differ between Redis (maxmemory-policy) and Memcached (LRU per slab class)?
  7. What happens when a big key (e.g., 100MB string) is deleted in Redis vs Memcached?
  8. Why does Redis consume slightly more RAM than Memcached for identical string key-values?
  9. How do you implement atomic counter increments in Memcached vs Redis?
  10. Which system is better suited for a distributed session store and why?

7. Gold Standard Answers

  1. Memcached uses OS threads with lock synchronization to process requests concurrently across multi-core CPUs. Redis uses a single-threaded event loop (epoll) to execute commands sequentially without lock overhead, eliminating race conditions for single-key operations.
  2. Memcached pre-allocates memory into fixed-size chunk pools called Slabs (e.g., 64B, 128B, 256B). Incoming key-values are assigned to the smallest slab class that fits, preventing OS-level memory fragmentation during frequent allocations/deletions.
  3. Redis 6.0+ offloads socket network I/O reading, client parsing, and response writing to background worker threads, but command execution logic remains strictly single-threaded on the main event loop to preserve atomicity.
  4. Memcached relies on client-side routing using consistent hashing algorithms (e.g., Ketama) to map keys to static nodes. Redis Cluster uses 16,384 server-managed Hash Slots where nodes route queries natively via cluster bus gossip.
  5. Memcached is computationally lighter, multi-threaded, and highly efficient for massive multi-terabyte pure caching fleets. Facebook built Mcrouter proxy to handle multi-region caching, connection pooling, and replication around Memcached at scale.
  6. Memcached applies LRU eviction per slab class; if a specific slab class fills up, items in that slab are evicted even if other slabs have free memory. Redis evaluates LRU/LFU across all keys in its unified dataset.
  7. Deleting a huge key in Redis blocks the main thread during memory deallocation unless using UNLINK (async background deletion). Memcached frees memory blocks instantly within its slab allocator.
  8. Redis wraps every value in a redisObject header (~16 bytes of metadata for encoding, LRU timestamp, refcount, type), adding slight memory overhead compared to raw Memcached key-value binary payloads.
  9. Memcached provides atomic incr and decr operations on numerical string values. Redis provides INCR, INCRBY, and full Lua scripting capabilities for complex multi-key condition checks.
  10. Redis is better suited because Redis Sentinel / Cluster provides primary-replica failover and optional persistence (AOF/RDB), ensuring users aren't logged out when a cache node restarts or crashes.

8. Common Mistakes

  • Choosing Memcached and expecting data to persist after server restarts or container redeployments.
  • Attempting to scale Redis vertically past 64GB RAM without tuning background snapshotting (fork overhead causes latency spikes).
  • Storing complex JSON objects in Memcached as strings, forcing expensive full re-serialization for minor field updates.
  • Running Redis KEYS * or huge DEL operations synchronously in high-throughput environments instead of SCAN and UNLINK.
  • Assuming Memcached provides automatic failover or replication without custom proxy layers like Mcrouter.

9. Keywords

Redis, Memcached, Multithreading, Event Loop, Slab Allocation, Memory Fragmentation, Mcrouter, Slab Class, UNLINK, robj Metadata, Ketama Consistent Hashing, Redis Sentinel, Redis 6.0 Multi-Threaded I/O.

10. Cheat Sheet

  • Architecture: Memcached = Multi-threaded (CPU scale-up); Redis = Single-threaded core (Threaded network I/O in v6+).
  • Data Model: Memcached = Strings / Blobs only; Redis = Strings, Hashes, Lists, Sets, Sorted Sets, Streams.
  • Persistence & HA: Memcached = Ephemeral cache only (No persistence/replication); Redis = RDB, AOF, Sentinel HA, Cluster.
  • Memory Allocator: Memcached = Slab allocation (no fragmentation); Redis = jemalloc with redisObject metadata overhead.
  • Eviction: Memcached = LRU per slab class; Redis = Configurable global LRU, LFU, or random.
  • Rule of Thumb: Pure multi-core string caching = Memcached; Advanced state, counters, HA caching = Redis.

11. Related Decisions