How to run a Redis-like distributed cache design in a 45-minute interview: consistent hashing, eviction, replication and failover, stampedes and hot keys.
Published September 21, 2026
This lesson is the interview version of designing a Redis/Memcached-like system: how to structure the answer and which deep dives to prepare. The full reference design is the case study Design a Distributed Cache in this chapter.
A cache keeps copies of frequently used data in memory so reads don't hit a slower database. A distributed cache spreads that data across many machines, because the working set is bigger than one machine's RAM, or the request rate is higher than one machine can serve. The design has three core problems: which node holds a key, what happens when nodes come and go, and what to evict when memory is full.
get, set (with TTL), delete. Anything richer (counters, lists, sorted sets)? App servers (cache client library)
│ hash(key) → node ← routing happens in the client, no extra hop
▼
┌─────────┐ ┌─────────┐ ┌─────────┐ each node: in-memory hash table
│ Node A │ │ Node B │ │ Node C │ ... + LRU eviction + TTL expiry
│ primary │ │ primary │ │ primary │
└────┬────┘ └────┬────┘ └────┬────┘
▼ ▼ ▼
replica replica replica async replication for failover
▲
Cluster config service (membership, which node owns which range) ← clients subscribe to changes
Explain the flow for a read (cache-aside, the most common pattern): the app asks the cache; on a miss it reads the database and writes the value into the cache with a TTL; on a hit it returns immediately.
The naive approach, node = hash(key) % N, breaks badly when N changes. Adding one node to 10 remaps about 90% of keys, and suddenly almost every request is a miss, so the database gets flattened.
Consistent hashing places both nodes and keys on a hash ring, and each key belongs to the next node clockwise. Adding or removing a node only moves the keys in that node's arc, roughly 1/N of the keys. Virtual nodes (each physical node appears at 100–200 points on the ring) even out the load and spread a failed node's keys across all survivors, instead of dumping them on one neighbour. Redis Cluster uses a close cousin: 16,384 fixed hash slots assigned to nodes.
get/put, the classic interview coding problem. Real systems often use approximate LRU (sample a few keys, evict the oldest) to avoid the memory cost of the list.Each primary has one or more replicas, updated asynchronously (a synchronous copy would double write latency). When a primary fails, heartbeats detect it, a replica is promoted, and the cluster config is updated so clients re-route. Be explicit about the trade-off: writes acknowledged by the old primary but not yet replicated are lost on failover. For a cache that's acceptable, and that's exactly why the database stays the source of truth.
hash % N and not noticing what happens when a node is added.Q: Cache-aside, read-through, write-through or write-behind: which would you use? A: Cache-aside (the app manages the cache) is the most common because it's simple and fails safe: if the cache is down, the app reads the database. Read-through/write-through move that logic into the cache layer. Write-through keeps the cache fresh at the cost of write latency. Write-behind (write to the cache, flush to the database later) is fast but risks losing writes, so it's rarely acceptable for important data.
Q: When you update the database, should you update the cache or delete the entry? A: Delete it. Updating risks writing an older value over a newer one when two updates race. Deleting forces the next read to load the current value. Delete after the database commit, and keep a TTL as a safety net in case a delete is lost.
Q: How do you handle a node that's slow rather than dead? A: Use tight client timeouts and treat a timeout as a miss (fall back to the database), with a circuit breaker so a sick node isn't hammered. Health checks that measure latency, not just liveness, can take it out of rotation. Slow nodes are often more damaging than dead ones because they tie up client threads.
Q: Redis or Memcached? A: Memcached is a simple, multi-threaded key-value cache, excellent for plain get/set of blobs. Redis is single-threaded per shard for commands, but offers rich data structures (lists, sorted sets, streams), persistence, replication and clustering. Choose Memcached for pure, simple caching at high throughput, and Redis when you need its data types or durability features.