Medium15 minDistributed Systems
UpdatedAug 5, 2026
Edit

Redis vs Memcached

CONCEPTS:Redis CachingMemcached Caching

Question Variations

  • "When is Memcached a better choice than Redis?"
  • "Can Redis be treated as a durable database?"
  • "How does sharding differ between Redis and Memcached?"

Why This Is Asked

This tests whether a candidate selects a cache from workload needs instead of popularity. Interviewers expect a comparison of data model, threading, persistence, topology, and operational trade-offs, while recognizing that both products are often used for disposable cache data.

Key Concepts

  • Redis: Rich data structures, atomic operations, replication, and optional persistence.
  • Memcached: Simple opaque key-value cache with multithreaded server execution.
  • Topology: Redis commonly centralizes richer state; Memcached clients shard keys across independent nodes.
  • Durability: Neither should become the sole system of record merely because it is fast.

Question Variations

  • “When is Memcached a better choice than Redis?”
  • “Can Redis be treated as a durable database?”
  • “How does sharding differ between Redis and Memcached?”

Answers by Technology

+ Add Variant

Expected Answer (Memcached)

Memcached is designed as a simple, disposable in-memory key-value cache. Clients typically hash keys across independent nodes; the server stores opaque values and is multithreaded, making it well suited to straightforward high-throughput cache workloads. It has no native rich collection types, persistence, replication, or server-side coordination semantics, which keeps the model operationally simple.

Choose Memcached when the workload is primarily large-scale ephemeral object caching and the application can tolerate node loss as ordinary cache misses. Choose Redis when the workload needs atomic data structures, richer coordination, replication, or persistence features. Neither choice removes the need for source-of-truth data, TTLs, capacity monitoring, and miss handling.

Why It Matters

Memcached’s simplicity is valuable when cache loss is acceptable. Expecting it to provide durable state, cross-node replication, or Redis-like atomic structures leads to incorrect application designs.

Example Code

import memjs from 'memjs';

const cache = memjs.Client.create(process.env.MEMCACHED_SERVERS);

export async function cacheProfile(id: string, profile: unknown): Promise<void> {
  await cache.set(`profile:${id}`, JSON.stringify(profile), { expires: 300 });
}

Common Mistakes

  • Treating Memcached as durable storage: Restart or eviction can remove entries at any time; the database must remain authoritative.
  • Assuming one Memcached node knows another node’s keys: Clients distribute keys, so adding or losing nodes changes placement and causes misses.

Follow-up Questions

  • What happens when a Memcached node fails? (Answer: Keys mapped to that node miss until the node returns or clients repopulate them.)
  • Why is Memcached good for opaque blobs? (Answer: Its simple key-value model avoids the overhead of richer server-side structures.)

References

Expected Answer (Redis 8.8.1)

Redis is a strong choice when the cache needs rich server-side data structures or atomic operations: hashes, sets, sorted sets, streams, counters, expiry, and Lua or functions can reduce application round trips. It also supports replication and persistence options, which can be useful for session state, rate limits, queues, and other volatile-but-important data. These capabilities add operational decisions around memory policy, topology, replication lag, and persistence.

For simple ephemeral blob caching, Redis is not automatically superior. Select it when its semantics solve a concrete need and size memory, eviction, and availability behavior deliberately. Even with persistence enabled, do not casually make Redis the only source of critical data without proving its durability and failover properties meet the required recovery objectives.

Why It Matters

Using Redis features appropriately can eliminate race conditions and simplify application coordination. Using it as an unexamined database substitute can create data-loss or consistency surprises during failover.

Example Code

import { createClient } from 'redis';

const redis = createClient({ url: process.env.REDIS_URL });

export async function allowRequest(userId: string): Promise<boolean> {
  const key = `rate-limit:${userId}`;
  const count = await redis.multi().incr(key).expire(key, 60, 'NX').exec();
  return Number(count[0]) <= 100;
}

Common Mistakes

  • Assuming Redis persistence makes every acknowledged write durable: Fsync and replication policies determine the remaining loss window.
  • Using an unbounded keyspace: Redis is memory-bound; missing TTLs and eviction planning can cause memory exhaustion.

Follow-up Questions

  • Why use a Redis hash instead of many string keys? (Answer: It can model related fields efficiently and supports atomic field operations.)
  • Does replication guarantee zero data loss? (Answer: No. Asynchronous replication can lag behind acknowledged writes.)

References