Chaturmind
LearnDSASystem DesignBlogPremium
Sign inGet started
Chaturmind

Structured learning paths for engineers who want to go deep. Written by practitioners.

Learn

  • Java
  • DSA
  • System Design
  • Spring Boot
  • AI / ML

Company

  • Blog
  • Premium
  • Contact

Legal

  • Privacy Policy
  • Terms of Service

© 2026 Chaturmind. All rights reserved.

Built for engineers who want to go deep.


← System Design Interview Playbook

Interview Framework

  • The 6-Step Design Framework

10 Case Studies

  • Design a URL Shortener
  • Design Twitter / X
  • Design WhatsApp
  • Design Netflix
  • Design a Rate Limiter
  • Design a Search Autocomplete
  • Design a Distributed Cache
  • Design a Notification Service
  • Design Uber / Ride Sharing
Chaturmind
← System Design Interview Playbook

Interview Framework

  • The 6-Step Design Framework

10 Case Studies

  • Design a URL Shortener
  • Design Twitter / X
  • Design WhatsApp
  • Design Netflix
  • Design a Rate Limiter
  • Design a Search Autocomplete
  • Design a Distributed Cache
  • Design a Notification Service
  • Design Uber / Ride Sharing
HomeLearnSystem DesignSystem Design Interview PlaybookDesign Cases
✓ FreeAdvanced· 13 min read

Design: Distributed Cache

Design a Redis-like distributed cache with consistent hashing, eviction, replication, and persistence.

Published April 26, 2025


Design: Distributed Cache

Requirements

  • GET/SET/DELETE operations < 1ms
  • Store up to 10TB of data (horizontally sharded)
  • LRU eviction, configurable TTL
  • High availability (replicated), no single point of failure
  • Optional: persistence to disk

Core Design

Client → [Cache Cluster Proxy / Router]
            ↓ consistent hashing
  [Shard 0] [Shard 1] [Shard 2] ... [Shard N]
  (Leader + Follower)

Data Partitioning

Consistent hashing assigns each cache node a range on the ring. When a node fails, only its segment is redistributed.

// Route key to the correct shard
String shard = consistentHash.getNode(key);
redisClient(shard).get(key);

LRU Eviction Implementation

class LRUCache {
    private final int capacity;
    private final Map<String, Node> map = new HashMap<>();
    private final DoublyLinkedList list = new DoublyLinkedList();

    public String get(String key) {
        if (!map.containsKey(key)) return null;
        Node node = map.get(key);
        list.moveToFront(node); // recently used
        return node.value;
    }

    public void put(String key, String value) {
        if (map.containsKey(key)) {
            Node node = map.get(key);
            node.value = value;
            list.moveToFront(node);
        } else {
            if (map.size() == capacity) {
                Node evicted = list.removeLast(); // evict LRU
                map.remove(evicted.key);
            }
            Node node = new Node(key, value);
            list.addToFront(node);
            map.put(key, node);
        }
    }
}

Replication

Each shard has a Leader + 1-2 Followers:
  Writes → Leader only
  Reads → Leader or Follower (consistency vs latency tradeoff)

On Leader failure:
  1. Sentinel/ZooKeeper detects via heartbeat
  2. Promotes Follower to Leader
  3. Clients re-route to new Leader

Cache Expiration

Lazy expiration: check TTL on access, delete if expired
Active expiration: background thread scans and deletes expired keys periodically

Redis approach: lazy + active (scan 20 random keys/sec per DB)

Persistence Options

OptionDescriptionUse Case
NoneMemory-only, fastestPurely ephemeral cache
Snapshot (RDB)Periodic dump to diskRecovery after restart
AOF (Append-Only File)Log every writeNear-zero data loss
HybridRDB + AOFBest of both

Cluster Communication

Gossip Protocol: nodes exchange cluster state periodically
→ Eventually consistent view of which nodes are alive
→ No central coordinator needed

Redis Cluster: 16384 hash slots, gossip protocol

Interview Tips

  1. LRU cache with O(1) get/put is a classic coding problem — know the HashMap + doubly linked list implementation.
  2. Consistent hashing for shard routing — explain how adding a node only moves 1/N of keys.
  3. Replication with automatic failover (sentinel pattern) is essential for 99.99% availability.

Previous

Design a Search Autocomplete

Next

Design a Notification Service

AI Tutor

Lesson: Design: Distributed Cache

Quick actions

AI responses can be inaccurate. Verify critical information.