# Redis vs Memcached > Choose Redis when you need server-side data structures, atomic multi-step operations, or built-in replication and persistence options. Choose Memcached for a disposable cache of opaque values when simple operations and multithreaded request handling fit the workload. Neither choice removes the need to design invalidation, hot-key handling, and protection for the database during cache failures. Source: https://sysround.com/compare/redis-vs-memcached Updated: 2026-11-05 ## Side by side | | Redis | Memcached | |---|---|---| | Data model | Redis: strings, hashes, sets, sorted sets, lists, and more | Memcached: opaque values addressed by keys | | Atomic operations | Commands, transactions, and scripts; cluster slot constraints apply | Single-item operations, counters, add, and CAS | | Persistence | Optional snapshots and append-only logging | Usually disposable; specialized warm-restart support exists | | Replication and failover | Built-in asynchronous replication; Sentinel or Cluster failover | No built-in replication or automatic replica promotion | | Horizontal partitioning | Redis Cluster hash slots or external sharding | Usually client or proxy routing, often consistent hashing | | CPU concurrency | Command execution mostly serial per shard; I/O can use threads | Multithreaded request handling within a server | | Memory management | Configurable eviction policies; type and encoding affect overhead | Slab-based allocation; item sizes affect memory efficiency | | Typical design role | Cache, counters, rankings, and short-lived shared state | Rebuildable cache of serialized objects | ## The differences that matter Redis can move logic to the data. A sorted set can maintain a leaderboard without fetching and rewriting the whole ranking. A script can check a rate-limit counter, update it, and set its expiry atomically on one shard. Memcached supports useful atomic primitives such as increment, add, and compare-and-swap, but more complex changes usually require application logic and retries. Failure recovery changes the backend capacity plan. Redis replicas can preserve cached data through some node failures, and persistence can help rebuild a node without fetching every value from the database. Ordinary Memcached deployments treat a failed node's contents as lost. Both still need request coalescing, controlled warming, and load shedding because failover or restart can produce a burst of misses. Partitioning affects which operations remain atomic. Redis Cluster assigns keys to hash slots, and multi-key transactions or scripts generally require the keys to share a slot. Memcached clients or proxies typically choose servers through hashing. In either system, adding nodes does not automatically solve a single hot key. There is no universal performance or memory winner. Memcached can process requests across multiple threads in one process, while Redis command execution is mostly serial within a shard. Actual capacity depends on payload sizes, commands, network limits, serialization, and key distribution. Compare memory use with representative objects, including allocator overhead, replicas, and any persistence-related headroom. Redis replication and persistence do not automatically make it a strongly consistent source of truth. Asynchronous failover can lose acknowledged writes, and persistence durability depends on configuration. Losing a cached profile may be acceptable; losing a seat allocation or payment decision usually is not. ## Choose Redis when - You need sorted sets, hashes, sets, or other structures that avoid repeatedly reading and rewriting whole objects. - A rate limiter needs an atomic check-and-update operation with expiry on a single shard. - A warm replica and automated failover would materially reduce the database load caused by cache-node failures. - You need optional persistence for shared state and can explicitly define the acceptable loss window and recovery behavior. ## Choose Memcached when - The workload is primarily get, set, and delete for serialized objects that can be rebuilt from a durable database. - Losing a cache node is acceptable, and the database is protected against the resulting miss traffic. - You want multithreaded request processing within each cache server and do not need Redis-specific structures or scripting. - Your existing client or proxy layer already handles hashing, membership changes, and cache-node failures. ## Worked example: A cache-node failure changes the database load Suppose a catalog serves 100,000 reads per second with a 95% cache hit rate across ten evenly loaded cache shards. The database normally handles 5,000 reads per second. If one shard loses all its cached data, about 9,500 previously cached reads per second can become additional database reads, bringing the total to roughly 14,500 until recovery. A Memcached design might accept this with spare database capacity, request coalescing, and throttled warming. Redis replication may preserve much of the shard's working set through failover, but costs replica memory and still requires timeout and miss-storm protection. Choose based on the recovery requirement, not just steady-state cache latency. ## In the interview - Start with the role: disposable cache or shared application state. State what happens if every cached key disappears, and whether any user-visible correctness depends on keeping it. - Name the required operation, not just the product. For example, explain why a rate limiter needs atomic increment-and-expire behavior, and how its keys stay within one Redis Cluster slot. - Estimate resident data, request rate, payload size, and backend miss capacity. Expect questions about replication overhead, object overhead, connection counts, and network bandwidth. - Walk through a node failure and a hot-key spike separately. Replicas and sharding address different problems, and neither guarantees that the database survives a cache miss storm. - Define timeout and failure policy. A recommendation cache may be bypassed, while a security rate limiter may need a conservative fallback rather than silently allowing every request. ## Common mistakes - Claiming Redis is always faster or Memcached always uses less memory without measuring a representative workload. - Saying Memcached has no atomic operations. It supports counters, add, and compare-and-swap, though not general multi-key transactions or server-side scripts. - Treating Redis persistence or replication as a guarantee that acknowledged writes cannot be lost. - Choosing a cache engine without explaining TTLs, invalidation, stampede prevention, and backend behavior when the cache is unavailable. ## Interview questions where it comes up - [Design a distributed cache](https://sysround.com/questions/design-distributed-cache): The comparison directly informs partition routing, eviction, replica recovery, and behavior when cache nodes disappear. - [Design a distributed rate limiter](https://sysround.com/questions/design-rate-limiter): Redis scripting and Memcached counter primitives lead to different implementations of atomic counting and expiry. - [Design a URL shortener like Bitly](https://sysround.com/questions/design-url-shortener): Redirect caching requires a choice between simple disposable values and additional replication or shared-state features. - [Design a news feed like Facebook](https://sysround.com/questions/design-news-feed): Redis sorted sets and lists offer different feed-cache update and pagination options from serialized Memcached values. - [Design a top K trending system](https://sysround.com/questions/design-top-k): Redis sorted sets can maintain shard-local rankings, while global top K still requires aggregation and hot-key handling. ## FAQ ### Is Redis faster than Memcached? Neither is universally faster. Results depend on command mix, value sizes, concurrency, network limits, and deployment configuration. Benchmark the intended workload and compare tail latency under failures as well as normal throughput. ### When should I use Memcached instead of Redis? Use Memcached when you need a disposable cache of opaque values and its basic operations cover the workload. It is especially reasonable when your infrastructure already handles routing and node loss. Choose Redis when its data structures, scripting, replication, or persistence solve a concrete requirement. ### Can Redis or Memcached be used as a database? Memcached is generally a cache, not a durable system of record. Redis can serve as primary storage for some applications, but you must evaluate persistence settings, asynchronous replication, failover data loss, and recovery procedures. For money or scarce inventory, do not assume a Redis acknowledgment alone establishes a durable business commitment. ## Related concepts - [Caching strategies](https://sysround.com/concepts/caching-strategies) - [Consistent hashing](https://sysround.com/concepts/consistent-hashing) - [Cache invalidation](https://sysround.com/concepts/cache-invalidation) - [Cache stampede and thundering herd](https://sysround.com/concepts/cache-stampede) - [Hot keys and hot partitions](https://sysround.com/concepts/hot-keys) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.