Bird
Raised Fist0

Consistent Hashing in Distributed Caches - Redis Cluster, Memcached

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
Client Application

Sends cache GET request with key

Client issues GET for key 'user:1234'

Protocol:Redis GET
BeforeClient has key 'user:1234' to fetch from cache
AfterGET request sent to Metadata Manager for routing
Consistent Hashing Ring Metadata Manager

Computes hash of key and finds vnode

Hashes 'user:1234' to vnode on ring

Protocol:Internal RPC
BeforeReceived GET request with key 'user:1234'
AfterMapped key to vnode responsible for it
Virtual Nodes (VNodes)

Maps vnode to physical Redis node

Determines Redis node owning vnode

Protocol:Internal RPC
BeforeVNode identified for key 'user:1234'
AfterPhysical Redis node selected for request
Redis Cluster Nodes

Processes GET request and returns cached value

Redis node looks up key and returns value

Protocol:Redis GET
BeforeGET request received for key 'user:1234'
AfterValue for 'user:1234' retrieved and sent back
Replication / Failover Layer

Ensures data consistency and failover readiness

Replicates data to standby nodes asynchronously

Protocol:Replication protocol
BeforePrimary Redis node holds latest data
AfterStandby nodes updated for failover
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   Client Application  │
└─────────────┬─────────┘
              │ Redis GET Request
              ▼
┌───────────────────────────────┐
│ Consistent Hash Ring Metadata  │
│ Manager                       │
└─────────────┬─────────────────┘
              │ Lookup hash ring & vnode
              ▼
┌───────────────────────────────┐
│ Virtual Nodes (VNodes)         │
│ (Logical partitions on ring)  │
└─────────────┬─────────────────┘
              │ Map vnode to physical node
              ▼
┌───────────────────────────────┐
│ Redis Cluster Nodes            │
│ (Cache data storage)           │
└─────────────┬─────────────────┘
              │ Replication sync / failover
              ▼
┌───────────────────────────────┐
│ Replication / Failover Layer   │
│ (Handles node failures)        │
└───────────────────────────────┘
Design Rationale

This architecture uses consistent hashing to route cache requests efficiently in a distributed Redis cluster. The Client Application sends a GET request which first hits the Consistent Hashing Ring Metadata Manager. This component hashes the key and identifies the responsible Virtual Node (VNode), a logical partition on the ring. The VNode maps to a physical Redis Cluster Node that stores the actual cached data. The Redis node processes the GET and returns the value. Meanwhile, the Replication / Failover Layer asynchronously replicates data to standby nodes to ensure high availability and fault tolerance. This design balances load evenly, minimizes cache misses during node changes, and provides resilience against node failures.

Primary Focus

✓

Practice

(1/5)
1. A large-scale messaging platform needs to isolate failures to prevent cascading outages during regional network partitions. Which architectural component best limits the blast radius by decoupling service dependencies?
easy
A. Use synchronous REST calls between microservices with retries
B. Use direct TCP socket connections between services for low latency
C. Implement asynchronous message queues with backpressure and dead-letter queues
D. Rely on a single monolithic database to coordinate all service state

Solution

  1. Step 1: Identify failure isolation mechanism

    Asynchronous message queues decouple services, buffering requests and preventing direct cascading failures during outages.

  2. Step 2: Evaluate alternatives

    Synchronous REST calls (A) cause blocking and cascading failures; monolithic DB (C) is a single point of failure; direct TCP (D) lacks buffering and backpressure.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Async queues buffer and isolate failures, limiting blast radius [check]
Hint: Async queues buffer failures, blocking calls cascade [check]
Common Mistakes:
2. In the request flow of a key-value store, at Step 4 the Gossip Protocol component receives a heartbeat from a node. What state does it update for that node?
easy
A. Updates the node's last known alive timestamp to maintain membership info
B. Marks the node as failed and triggers immediate data rebalancing
C. Resets the vector clock for all keys stored on that node
D. Triggers a consistent hashing ring reshuffle to redistribute keys

Solution

  1. Step 1: Understand Gossip Protocol heartbeat handling

    Gossip updates the membership list by refreshing the last alive timestamp for the node sending the heartbeat.

  2. Step 2: Eliminate incorrect states

    Marking node as failed contradicts receiving heartbeat. Vector clocks are unrelated to node liveness. Consistent hashing ring changes only on node join/leave, not heartbeat.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Heartbeat updates node's alive timestamp in gossip membership [check]
Hint: Heartbeat refreshes node's alive timestamp in gossip membership [OK]
Common Mistakes:
3. You need to handle 1 million product updates per minute in the catalog without blocking user searches. Which component best handles this high write throughput while ensuring eventual consistency?
easy
A. Use a distributed log system like Kafka to buffer and asynchronously process updates
B. Use an in-memory cache like Redis as the primary data store for product updates
C. Use a NoSQL key-value store with synchronous writes for every update
D. Use a relational database with immediate consistency for all writes

Solution

  1. Step 1: Identify write throughput handling

    Relational DBs (A) and synchronous NoSQL writes (C) block on writes, limiting throughput. Redis (D) lacks durability guarantees for primary storage.

  2. Step 2: Recognize Kafka's role

    Kafka buffers high write volume asynchronously, decoupling writes from reads and enabling eventual consistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka buffers writes asynchronously -> high throughput, eventual consistency [check]
Hint: Buffer writes asynchronously with Kafka for high throughput [check]
Common Mistakes:
4. If Redis persistence (RDB or AOF) is disabled in a caching layer, what exact failure occurs when the Redis server crashes unexpectedly?
medium
A. Redis automatically recovers data from DynamoDB backups to restore cache state
B. All cached data is lost, causing cache misses and increased load on the primary database
C. Clients receive stale data from Redis until manual cache flush is performed
D. Redis switches to read-only mode and serves stale data until restarted

Solution

  1. Step 1: Understand Redis persistence modes and crash impact

    Without RDB or AOF persistence, Redis stores data only in memory; crash causes total data loss.

  2. Step 2: Trace failure impact on cache and database load

    Cache data loss leads to cache misses, increasing load on the primary database until cache is warmed again.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Redis without persistence -> data lost on crash -> cache misses spike [check]
Hint: No Redis persistence -> crash wipes cache, DB load spikes [check]
Common Mistakes:
5. At 10x scale, which MongoDB component is most likely to become the bottleneck first when using the bucket pattern for time-series data, and why?
hard
A. The application server, because it cannot generate bucket IDs fast enough for writes.
B. The MongoDB query router (mongos), because it must maintain metadata for all buckets and route writes precisely.
C. The shard servers, because bucket documents grow large and cause frequent document splits and index overhead.
D. The network layer, because increased bucket writes saturate bandwidth between shards.

Solution

  1. Step 1: Identify bucket pattern scaling challenges

    Bucket pattern creates many bucket documents requiring precise routing by mongos.

  2. Step 2: Mongos metadata overhead

    Mongos maintains routing metadata and must route each write to correct shard and bucket, increasing load at scale.

  3. Step 3: Compare other components

    Shard servers handle writes but document splits are less frequent; network saturates later; app server bottleneck unlikely.

  4. Final Answer:

    Option B -> Option B

  5. Quick Check:

    Mongos routing metadata load grows fastest at 10x scale [check]
Hint: Mongos routing metadata overload is first bottleneck at scale [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard