All quizzesMedium
Database Scaling — Series 2
Preview — 3 of 10 questions
A database was originally sharded across 4 nodes by hash(user_id) % 4. The team now needs to grow to 8 nodes. What's the core challenge with resharding, and what technique reduces its impact?
AResharding never requires moving any existing data — new nodes simply start empty and grow from new writes only
BThe only way to reshard is to delete all existing data and have users re-submit it
CResharding is only a concern for NoSQL databases and never affects relational databases
DChanging the shard count with a simple % N hash means almost every key's target shard changes at once (since hash(key) % 4 and hash(key) % 8 disagree for most keys), forcing a massive, disruptive bulk data migration. Consistent hashing (or a similar technique) minimizes this by ensuring that adding nodes only remaps a small fraction of keys — roughly 1/N of the data — rather than nearly all of it
A database is sharded by hash(customer_id), but one particular enterprise customer generates 40% of all traffic. What problem does this create, and what are common mitigations?
AThis creates a "hot shard": the shard holding that customer's data receives disproportionately more load than every other shard, becoming a bottleneck even though the overall cluster has plenty of spare capacity elsewhere. Mitigations include further splitting that one customer's data across multiple shards (sub-sharding a hot key), or moving that customer's shard onto more powerful dedicated hardware
BHot shards only occur when a database has fewer than 2 total shards
CThe correct fix for a hot shard is always to delete the high-traffic customer's data
DSharding by a hash function makes hot shards structurally impossible, by definition
A orders table is sharded by customer_id, but a report needs to join orders with a products table that isnt sharded the same way. Why is this harder than a normal single-database join, and whats a common approach?
ACross-shard joins work exactly like single-database joins, with zero additional design considerations
BThe database engine automatically handles cross-shard joins with no performance difference from a local join
CA join across shards means the data needed to satisfy the query lives on different, physically separate machines — the database can't just scan one local table. Common approaches include denormalizing frequently-joined data (duplicating product details onto the orders record itself) or having the application layer fetch from each shard separately and join the results in application code, since not all sharded systems support efficient distributed joins
DThe only valid solution is to permanently merge all shards back into a single unsharded database
Sign up free to play
Answer all 10 questions (7 more), see explanations for every answer, and track your score.