Bird
Raised Fist0

Why Consistent Hashing and What Modular Hashing Cannot Handle

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

Receives client HTTP request

Accepts incoming request and forwards to partitioning service

Protocol:HTTP
BeforeClient request arrives at load balancer
AfterRequest forwarded to partitioning service
Partitioning Service

Computes partition using consistent hashing

Maps request key to storage node using consistent hashing ring

Protocol:Internal RPC
BeforePartitioning service has cluster membership info from ZooKeeper
AfterPartitioning service identifies target storage node
Storage Nodes (Cassandra)

Stores data on selected node

Persists data partition and responds with success

Protocol:CQL (Cassandra Query Language)
BeforeStorage node is healthy and ready to accept writes
AfterData is durably stored on the node
Metadata Service (ZooKeeper)

Updates cluster membership info

Detects node join/leave events and updates consistent hashing ring

Protocol:ZAB Protocol
BeforeCluster membership info is current
AfterCluster membership reflects latest node changes
Monitoring & Alerting (Prometheus + Grafana)

Collects metrics and triggers alerts

Monitors node health and partitioning service metrics

Protocol:Prometheus scrape
BeforeMetrics are collected periodically
AfterAlerts raised if node failures or imbalances detected
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────┐
│   Load Balancer   │
└─────────┬─────────┘
          │ HTTP Request
          ▼
┌───────────────────────────┐
│   Partitioning Service    │
│  (Consistent Hashing)     │
└─────────────┬─────────────┘
              │ Partition Key
              ▼
┌───────────────────────────┐
│ Storage Nodes (Cassandra) │
│  (Distributed DB Cluster) │
└─────────────┬─────────────┘
              │ Node Status Query
              ▼
┌───────────────────────────────┐
│ Metadata Service (ZooKeeper)  │
│  (Cluster Membership & Config)│
└─────────────┬─────────────────┘
              │ Metrics & Alerts
              ▼
┌─────────────────────────────────────────┐
│ Monitoring & Alerting (Prometheus + Graf)│
│ a)                                      │
└─────────────────────────────────────────┘
Design Rationale

This architecture demonstrates why consistent hashing is essential for partitioning data across storage nodes. The Load Balancer routes client requests to the Partitioning Service, which uses consistent hashing to map keys to nodes. Unlike modular hashing, consistent hashing gracefully handles node joins and leaves by minimizing data movement, as reflected in ZooKeeper's cluster membership updates. Storage Nodes (Cassandra) store data partitions reliably, while Monitoring & Alerting systems track health and performance. This design ensures scalability and fault tolerance by decoupling partitioning logic from physical node changes, avoiding the costly remapping that modular hashing would require.

Primary Focus

✓

Practice

(1/5)
1. A browser needs to resolve a domain name to an IP address but wants to avoid repeated queries to external servers for the same domain within a short time. Which component in the DNS resolution chain primarily handles this optimization?
easy
A. The authoritative DNS server for the domain, which caches recent queries to speed up responses
B. The local DNS resolver (stub resolver) on the user's machine, which caches recent lookups to reduce network calls
C. The root DNS server, which maintains a cache of all domain-to-IP mappings globally
D. The recursive DNS server, which never caches results and always queries authoritative servers

Solution

  1. Step 1: Identify the role of the local DNS resolver

    The local DNS resolver (stub resolver) on the user's machine caches recent DNS lookups to avoid repeated network queries for the same domain within a short time.

  2. Step 2: Eliminate other options

    Authoritative DNS servers provide domain data but do not cache queries for clients. Root servers do not cache all mappings globally and are rarely queried directly. Recursive DNS servers do cache results to improve performance, so The recursive DNS server, which never caches results and always queries authoritative servers is incorrect.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Local resolver caches to reduce network calls [check]
Hint: Local resolver caches recent lookups to reduce queries [check]
Common Mistakes:
2. A system expects 1 million daily active users (DAU) with an average of 50 requests per user per day. Which component is best suited to handle the peak QPS estimation for capacity planning?
easy
A. Use a load balancer's metrics to estimate peak QPS from incoming traffic patterns
B. Use a relational database to directly measure QPS by counting requests in real-time
C. Use client-side logs aggregated asynchronously to estimate QPS after the fact
D. Use a CDN to estimate QPS by counting cache hits and misses

Solution

  1. Step 1: Identify component that reflects real-time incoming traffic

    Load balancer metrics provide immediate, accurate QPS data as they handle all incoming requests before backend processing.

  2. Step 2: Eliminate other options

    Relational DB counting is too slow and adds overhead; client logs are delayed and incomplete; CDN metrics reflect cached content, not all requests.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Load balancer metrics reflect real-time QPS accurately [check]
Hint: Load balancer metrics reflect real-time QPS [check]
Common Mistakes:
3. In a distributed lock system using ZooKeeper, at step 4 the client attempts to acquire the lock by creating an ephemeral sequential node. What happens if the client crashes immediately after creating this node but before confirming lock ownership?
easy
A. ZooKeeper automatically deletes the ephemeral node, releasing the lock
B. The ephemeral node remains until manually deleted, causing a deadlock
C. The client retains the lock until a timeout expires
D. The lock is transferred to the next waiting client immediately

Solution

  1. Step 1: Understand ephemeral node semantics

    Ephemeral nodes in ZooKeeper are automatically deleted when the client session ends (e.g., crash), preventing deadlocks (A) and stale locks.

  2. Step 2: Trace lock ownership after crash

    Since the ephemeral node is deleted, the next client waiting for the lock will be notified, but the lock is not immediately transferred (D) until they acquire it explicitly.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Ephemeral node deletion on client crash -> lock released [check]
Hint: Ephemeral nodes vanish on client crash, freeing locks [check]
Common Mistakes:
4. Without the shard-level cache in the faceted search system, what exactly breaks during high query load spikes?
medium
A. The Query Coordinator fails to merge results correctly causing incorrect counts
B. Shard nodes become overloaded, causing increased query latency and timeouts
C. Queries return stale facet counts due to delayed cache invalidation
D. The inverted index becomes inconsistent and returns wrong documents

Solution

  1. Step 1: Understand shard-level cache role

    The cache reduces load on shard nodes by serving frequent queries quickly, preventing overload during spikes.

  2. Step 2: Trace failure without cache

    Without cache, all queries hit shard nodes directly, causing CPU and I/O overload, increasing latency and timeouts.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Cache absence -> shard overload -> latency spikes [check]
Hint: No cache -> shard overload -> latency spikes [check]
Common Mistakes:
5. For a chat system requiring low latency and fault tolerance, which architecture is best when mobile clients have intermittent connectivity?
medium
A. Use gRPC streaming for persistent connections to push messages instantly
B. Use a message queue with client-side polling and exponential backoff
C. Use WebSocket connections with server-side buffering and reconnection logic
D. Use HTTP long polling with immediate retries on failure

Solution

  1. Step 1: Evaluate client connectivity constraints

    Mobile clients have intermittent connectivity; gRPC streaming (A) requires persistent connections, which mobile networks may not support well. HTTP long polling (D) causes overhead and latency.

  2. Step 2: Compare WebSocket with server buffering vs polling

    WebSocket with server-side buffering and reconnection (C) balances low latency and fault tolerance better than client polling (B), which increases latency and load.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    WebSocket + buffering + reconnection -> best for intermittent mobile [check]
Hint: WebSocket buffers and reconnects for flaky mobile networks [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