Sharding easy
What is the most significant operational benefit of using 'Hash-Based' sharding over 'Range-Based' sharding?
- A It significantly improves the performance of range scans and sorted results.
- B It distributes both the data storage and the incoming traffic more uniformly across the cluster, regardless of the order of keys.
- C It is vastly easier for a human to debug and manually trace where a specific key is located.
- D It allows the cluster to be resized instantly without moving any existing data.
Answer: B. It distributes both the data storage and the incoming traffic more uniformly across the cluster, regardless of the order of keys.
Hashing 'mixes up' the data. Even if you insert records sequentially (Order 1, Order 2, Order 3), the hash function will map them to completely different shards (e.g., Shard 5, Shard 1, Shard 9). This ensures that every server in the cluster is working at the same time, preventing the 'Hotspot' problem where only the newest shard is under pressure. This gain in uniformity comes at the cost of 'Order Preservation'—you can no longer efficiently ask for 'all items from the last hour' without querying every single shard in the system.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In an E-Commerce platform, why might you choose to shard the `Orders` table by `user_id` rather than the more obvious `order_id`?
- In the context of database scaling, what is the fundamental difference between 'Vertical Partitioning' and 'Horizontal Partitioning' (Sharding)?
- If Shard A fails in a large cluster, and its incoming traffic is automatically re-routed to Shard B, what is the risk of a 'Cascading Failure'?
- In a standard 'Modulo Sharding' setup (`key % N`), what is the primary consequence of adding a new server to the cluster (increasing N from 10 to 11)?
- From an engineering perspective, when should you choose 'Vertical Scaling' (a bigger server) over 'Horizontal Scaling' (Sharding)?
- Which sharding strategy is mathematically optimized for efficient 'Range Scans' (e.g., retrieving all records created between January and March)?