Bird
Raised Fist0

Distributed Cache Design - Consistent Hashing for Cache Node Assignment

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

Sends data request

Client issues a request for a data key

Protocol:HTTP
BeforeClient has data key to fetch but no cache info
AfterRequest sent to Cache Client Library for routing
Cache Client Library

Queries consistent hash ring metadata

Fetches latest hash ring info to map key to cache node

Protocol:gRPC
BeforeCache Client Library has request but no node mapping
AfterCache Client Library knows which Cache Node to query
Cache Nodes (Redis Cluster)

Receives GET request for data key

Checks local cache for requested key

Protocol:Redis GET
BeforeCache Node has cache data or is empty for key
AfterCache Node either returns cached data or misses
Cache Nodes (Redis Cluster)

On cache miss, requests data from backend

Fetches data from Backend Data Store to populate cache

Protocol:Database Query
BeforeCache Node does not have requested key cached
AfterCache Node caches data and returns it to client library
Cache Client Library

Returns data to client

Delivers cached or backend-fetched data to Client Application

Protocol:HTTP Response
BeforeCache Client Library has data from Cache Node
AfterClient Application receives requested data
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│       Client Application      │
└───────────────┬───────────────┘
                │ Web Request (HTTP)
                ▼
┌───────────────────────────────┐
│      Cache Client Library      │
│  (uses Consistent Hash Ring)   │
└───────────────┬───────────────┘
                │ Metadata Query (gRPC)
                ▼
┌───────────────────────────────┐
│Consistent Hash Ring Metadata   │
│Store (ZooKeeper/etcd)          │
└───────────────┬───────────────┘
                │ Cache Node Selection Info
                ▼
┌───────────────────────────────┐
│      Cache Nodes              │
│    (Redis Cluster)            │
└───────────────┬───────────────┘
                │ Redis GET
                ▼
┌───────────────────────────────┐
│     Backend Data Store         │
│       (Database)               │
└───────────────────────────────┘
Design Rationale

This architecture uses consistent hashing metadata stored in ZooKeeper or etcd to map data keys to specific cache nodes in a Redis cluster. The Client Application sends a request to the Cache Client Library, which queries the metadata store to determine the correct cache node. The cache node attempts to serve the request from its local cache. On a cache miss, it fetches data from the backend data store, caches it, and returns it. This design ensures even distribution of keys across cache nodes and minimizes cache rebalancing when nodes join or leave, improving scalability and fault tolerance.

Primary Focus

✓

Practice

(1/5)
1. A large e-commerce platform needs to shard its user data to support efficient range queries on user signup dates. Which sharding strategy best fits this requirement?
easy
A. Directory-based sharding to map each user ID to a specific shard via a lookup table
B. Hash-based sharding to evenly distribute users across shards regardless of signup date
C. Range-based sharding to group users by signup date intervals for efficient range queries
D. Random sharding to balance load without considering signup date

Solution

  1. Step 1: Identify query pattern

    Range queries on signup dates require data locality by date ranges to avoid scatter-gather queries.

  2. Step 2: Match sharding strategy

    Range-based sharding partitions data by contiguous key ranges, enabling efficient range scans.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Range sharding groups data by key intervals for range queries [check]
Hint: Range sharding groups contiguous keys for range queries [check]
Common Mistakes:
2. In the News Feed system, at step 4 the Delivery Worker reads from the fan-out queue to push updates to followers. What happens if the follower's cache entry for the feed is expired at this step?
easy
A. The Delivery Worker fetches the latest feed snapshot from the database before pushing
B. The Delivery Worker sends a stale cached feed to the follower
C. The Delivery Worker retries the message later without updating the cache
D. The Delivery Worker skips sending the update and marks it as delivered

Solution

  1. Step 1: Trace Delivery Worker decision at Step 4 -- follower cache TTL expired

    If the cache is expired, the Delivery Worker must fetch fresh data to ensure the follower receives the latest feed snapshot.

  2. Step 2: Evaluate other options

    Skipping (A) causes missed updates; retrying without cache update (C) delays delivery; sending stale data (D) violates freshness guarantees.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Expired cache triggers DB fetch for fresh feed [check]
Hint: Expired cache triggers DB fetch before delivery [check]
Common Mistakes:
3. In the log aggregation pipeline, at Step 4 the Log Processor reads from Kafka and enriches logs with metadata. What happens if the enrichment service is temporarily unavailable at this step?
easy
A. The Log Processor buffers logs locally and retries enrichment until successful
B. The Log Processor skips enrichment and forwards raw logs downstream
C. The Log Processor commits Kafka offsets immediately and drops logs
D. The Log Processor crashes and restarts without processing logs

Solution

  1. Step 1: Trace Log Processor behavior at Step 4

    It reads logs from Kafka and enriches them before forwarding.

  2. Step 2: Understand failure handling

    If enrichment service is down, buffering and retrying prevents data loss and ensures enrichment.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Buffer and retry enrichment -> no data loss or offset commit [check]
Hint: Buffer and retry enrichment to avoid data loss [check]
Common Mistakes:
4. A high-traffic e-commerce platform expects sudden spikes of 1 million orders per minute. Which component best handles decoupling order intake from downstream inventory updates to maintain responsiveness?
easy
A. An in-memory cache with TTL eviction to buffer incoming orders
B. A relational database with strong ACID transactions for immediate consistency
C. A distributed message queue with partitioning and durable storage
D. A REST API gateway that throttles requests to downstream services

Solution

  1. Step 1: Identify decoupling need

    Immediate consistency via relational DB (A relational database with strong ACID transactions for immediate consistency) blocks on writes, causing latency spikes. In-memory cache (An in-memory cache with TTL eviction to buffer incoming orders) lacks durability and ordering guarantees. API gateway throttling (A REST API gateway that throttles requests to downstream services) limits throughput but doesn't decouple processing.

  2. Step 2: Durable queue with partitioning

    A distributed message queue (A distributed message queue with partitioning and durable storage) buffers spikes, partitions workload, and guarantees durability, enabling asynchronous downstream processing.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Distributed queue partitions spikes, ensures durability, decouples processing [check]
Hint: Use durable queues to buffer spikes and decouple processing [OK]
Common Mistakes:
5. At 10x scale, which component in a real-time chat system implementing CAP theorem fails first and why?
hard
A. The database fails first due to increased write amplification
B. The message queue fails first due to partition key hotspots causing uneven load
C. Chat servers fail first because WebSocket connections are stateful and cannot be resharded easily
D. The load balancer fails first due to inability to handle increased connection churn

Solution

  1. Step 1: Identify stateful bottleneck

    Chat servers maintain WebSocket connections statefully, limiting horizontal scaling.

  2. Step 2: Understand scaling impact

    At 10x scale, existing WebSocket connections cannot be moved, causing chat servers to saturate first.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Stateful WebSocket servers bottleneck scaling before DB or load balancer [check]
Hint: Stateful WebSocket servers bottleneck scaling first [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