Bird
Raised Fist0

Rendezvous Hashing - Alternative Approach and Trade-offs

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Client Applications

Send request for data node assignment

Client sends HTTP request to Lookup Service to get assigned node

Protocol:HTTP
BeforeClient knows data key but not assigned node
AfterRequest sent to Rendezvous Hashing Lookup Service
Rendezvous Hashing Lookup Service

Compute scores for all active nodes

Calculates hash scores for each node using key and node ID

Protocol:Internal computation
BeforeLookup Service has current active node list from Membership Service
AfterHighest scoring node selected for the key
Rendezvous Hashing Lookup Service

Return assigned node info to client

Sends assigned Data Node address back to client

Protocol:HTTP Response
BeforeNode selected but client unaware
AfterClient receives assigned Data Node info
Node Membership Service

Receive membership updates from Zookeeper

Watches Zookeeper for node join/leave events and updates active list

Protocol:Zookeeper Watch
BeforeMembership list may be stale
AfterMembership list updated with latest active nodes
Node Registry Store (Apache Zookeeper)

Notify Membership Service of node changes

Sends watch event on node metadata changes

Protocol:Zookeeper Watch Event
BeforeNode metadata stored but not pushed
AfterMembership Service notified of node membership change
Data Nodes

Serve client data requests

Client connects to assigned Data Node to read/write data

Protocol:Custom RPC or REST
BeforeClient has assigned node info
AfterData Node processes client request
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│       Client Applications      │
└───────────────┬───────────────┘
                │ HTTP Request: Get Node Assignment
                ▼
┌───────────────────────────────┐
│ Rendezvous Hashing Lookup Srv  │
│  - Computes node scores        │
│  - Selects highest score node  │
└───────────────┬───────────────┘
                │ gRPC
                ▼
┌───────────────────────────────┐
│     Node Membership Service    │
│  - Tracks active nodes         │
│  - Updates membership from ZK  │
└───────────────┬───────────────┘
                │ Zookeeper Watch
                ▼
┌───────────────────────────────┐
│ Node Registry Store (Zookeeper)│
│  - Stores node metadata        │
│  - Provides membership info    │
└───────────────┬───────────────┘
                │
                ▼
┌───────────────────────────────┐
│          Data Nodes            │
│  - Store actual data           │
│  - Serve client requests       │
└───────────────────────────────┘
Design Rationale

This architecture uses a Rendezvous Hashing Lookup Service to assign clients to data nodes dynamically. Clients request node assignments via HTTP, and the Lookup Service computes hash scores for all active nodes to select the best node for the given key. The Node Membership Service maintains an up-to-date list of active nodes by watching the Node Registry Store in Apache Zookeeper, which stores node metadata and membership info. This design decouples membership management from hashing logic, allowing dynamic updates without client disruption. Data Nodes serve actual data requests after assignment. The vertical flow emphasizes the dependency chain: client requests flow down to lookup, membership updates flow up from Zookeeper, ensuring consistent and scalable node assignment.

Primary Focus

✓

Practice

(1/5)
1. A CI/CD system must ensure that build artifacts are immutable and versioned for traceability. Which component is primarily responsible for this requirement?
easy
A. The artifact registry, which stores and versions build outputs
B. The rollback manager, which tracks previous deployment states
C. The test runner, which validates artifact correctness
D. The deployment orchestrator, which manages rollout strategies

Solution

  1. Step 1: Identify artifact immutability responsibility

    The artifact registry stores build outputs as immutable, versioned entities to ensure traceability and reproducibility.

  2. Step 2: Eliminate other components

    The deployment orchestrator manages rollout but does not store artifacts; test runner validates but does not version; rollback manager tracks deployments but not artifacts.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Artifact registry ensures immutable, versioned storage [check]
Hint: Immutable artifacts live in the registry, not deployer [check]
Common Mistakes:
2. In the hotel booking system, at step 4 of the reservation flow, the Inventory Service checks room availability. What state does the Inventory Service report if the room was reserved moments ago but the Reservation Service has not yet confirmed the booking?
easy
A. The room is marked as available because the reservation is not yet confirmed
B. The room is marked as temporarily unavailable due to a pending reservation lock
C. The room is marked as unavailable only after payment confirmation
D. The room availability status is unknown until the Reservation Service sends a confirmation event

Solution

  1. Step 1: Trace Inventory Service state at step 4

    The Inventory Service relies on confirmed reservation events to update availability. Pending reservations may not yet be reflected.

  2. Step 2: Understand event-driven state updates

    Without confirmation, Inventory cannot mark the room as unavailable. It waits for Reservation Service confirmation events to update state, so availability is unknown until then.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Inventory waits for confirmation events before updating availability [check]
Hint: Inventory updates only after confirmed reservation events [check]
Common Mistakes:
3. In a load balancer using Weighted Round Robin, at step 5 the balancer receives a new request. The current server weights are: Server A=5, Server B=3, Server C=2. Which server does the balancer select next?
easy
A. Server A, because Weighted Round Robin cycles through servers proportionally to their weights
B. Server B, because it has fewer active connections than Server A
C. Server C, because it was least recently selected
D. Server A, because it has the highest static weight

Solution

  1. Step 1: Understand Weighted Round Robin operation

    Weighted Round Robin cycles through servers, selecting each server multiple times proportional to its weight before moving to the next.

  2. Step 2: Apply weights to selection

    Server A with weight 5 will be selected more frequently than B or C. At step 5, the balancer continues cycling respecting weights.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Weighted Round Robin respects weights in cycling, not just highest weight always [check]
Hint: Weighted Round Robin cycles servers proportional to weights, not just highest weight [check]
Common Mistakes:
4. If the shared database in a microservices architecture is unavailable, what is the immediate failure impact on services that rely on it?
medium
A. Services queue requests internally and retry database operations asynchronously
B. Services block on database calls, causing request timeouts and degraded user experience
C. API Gateway reroutes requests to backup services without database dependency
D. Services automatically switch to local caches and continue operating normally

Solution

  1. Step 1: Understand failure impact of shared database outage

    Services depending on the shared DB cannot proceed with reads/writes, causing blocking or errors.

  2. Step 2: Evaluate fallback mechanisms

    Some microservices implement internal queuing and retry logic to handle transient DB failures asynchronously, preventing immediate request failures.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Internal queuing and retries mitigate DB outage impact [check]
Hint: Queue and retry internally to survive DB outages [check]
Common Mistakes:
5. For a mobile app requiring real-time notifications at 10x scale, which architecture is better and why?
medium
A. Use WebSockets with a scalable connection broker to handle mobile client limitations
B. Use gRPC streaming for persistent connections to push notifications
C. Use long polling HTTP requests to simulate real-time updates
D. Use periodic polling every 5 seconds to reduce server load

Solution

  1. Step 1: Evaluate mobile client support

    gRPC streaming (Use gRPC streaming for persistent connections to push notifications) is efficient but poorly supported on many mobile platforms, causing compatibility issues.

  2. Step 2: WebSockets with connection broker

    WebSockets (Use WebSockets with a scalable connection broker to handle mobile client limitations) are widely supported on mobile and, with a scalable broker, can handle millions of connections efficiently.

  3. Step 3: Polling drawbacks

    Long polling (Use long polling HTTP requests to simulate real-time updates) and periodic polling (Use periodic polling every 5 seconds to reduce server load) increase latency and server load, unsuitable for real-time at scale.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    WebSockets + broker -> scalable, mobile-friendly real-time [check]
Hint: WebSockets scale better on mobile than gRPC streaming [OK]
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