Design consistent hashing for sharding

Quick Overview

This question evaluates understanding of consistent hashing, replica placement, dynamic membership, weighted load distribution, rebalancing impact, and related distributed-systems competencies for routing and sharding.

Design consistent hashing for sharding

Company: DoorDash

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design and implement a consistent-hashing based router that maps arbitrary keys to backend servers. Requirements: ( 1) Describe the hash ring, token assignment, and use of virtual nodes to smooth load; ( 2) Support addServer(id, weight) and removeServer(id) with minimal key movement; ( 3) Implement getServer(key) and explain the expected percentage of keys that move when servers join/leave; ( 4) Extend to replicate each key to R distinct servers and discuss read/write semantics under failures; ( 5) Analyze time/space complexity and storage overhead.

Quick Answer: This question evaluates understanding of consistent hashing, replica placement, dynamic membership, weighted load distribution, rebalancing impact, and related distributed-systems competencies for routing and sharding.

|Home/System Design/DoorDash
DoorDash logo
DoorDash
Sep 6, 2025, 12:00 AM
hardSoftware EngineerOnsiteSystem Design
20
0

Design a Consistent-Hashing Router with Replication

You are building a stateless router that maps arbitrary keys (for example, request IDs or cache keys) to backend servers. The router must support dynamic membership, weighted capacity, and multi-replica placement while minimizing key movement when servers join or leave.

Requirements:

  1. Hash Ring and Load Smoothing
    • Describe the consistent-hash ring, token assignment, and how virtual nodes (vnodes) smooth load imbalance.
  2. Membership Operations
    • Provide addServer(id, weight) and removeServer(id) that change as few key-to-server assignments as possible.
  3. Key Lookup and Rebalancing Impact
    • Implement getServer(key) and explain the expected percentage of keys that move when servers join or leave (both equal-weight and weighted cases).
  4. Replication to R Distinct Servers
    • Extend the design to place each key on R distinct servers and discuss read/write semantics and client behavior under server failures.
  5. Complexity and Overhead
    • Analyze time complexity, space complexity, and storage/replication overhead. Include any operational guardrails or validation strategies you would use.

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...