Shard key selection in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding shard key impact on data distribution

Imagine you have a large database storing user profiles. You want to split this data across multiple servers (shards) to improve performance. Which shard key choice will most evenly distribute the data?

A User's country code (e.g., US, IN, UK)

B User's signup date (YYYY-MM-DD)

C User's unique ID (a random UUID)

D User's last name initial (A-Z)

💡 Hint

Think about which key has the most randomness and uniqueness to spread data evenly.

A random UUID as a shard key spreads data evenly because it has high cardinality and randomness. Country code or last name initial have limited values causing uneven distribution. Signup date can cause hotspots if many users sign up on the same day.

❓ Architecture

intermediate

Choosing shard key for query efficiency

You design a product catalog system where users often search products by category and price range. Which shard key will optimize query speed for these searches?

A Product category

B Product creation timestamp

C Product ID

D Product price

💡 Hint

Consider which shard key aligns with common query filters to reduce cross-shard queries.

Sharding by product category groups similar products together, so queries filtering by category hit fewer shards. Price or creation timestamp are continuous values causing range queries to span many shards. Product ID is unique but unrelated to query patterns.

❓ scaling

advanced

Handling shard key hotspots in a social media app

A social media app uses user ID as the shard key. Suddenly, a celebrity user causes a hotspot with millions of requests to their shard. What is the best architectural approach to reduce this hotspot?

A Implement a cache layer in front of the database for popular user data

B Change shard key to user location to spread load geographically

C Increase the number of shards without changing the shard key

D Use a composite shard key combining user ID and request timestamp

💡 Hint

Think about reducing load on the hotspot shard without major data reshuffling.

Caching popular user data reduces direct database hits on the hotspot shard. Changing shard key or increasing shards alone won't solve the hotspot because the celebrity's data is concentrated. Composite keys add complexity but don't reduce hotspot load effectively.

❓ tradeoff

advanced

Tradeoffs of choosing a monotonically increasing shard key

What is a major downside of using a monotonically increasing value (like timestamp or auto-increment ID) as a shard key?

A It prevents horizontal scaling of the database

B It increases network latency between shards

C It makes data replication impossible

D It causes uneven data distribution leading to shard hotspots

💡 Hint

Consider how new data is assigned to shards over time.

Monotonically increasing shard keys cause new data to be written to the same shard, creating hotspots and uneven load. This reduces write scalability. It does not inherently increase latency, prevent replication, or block scaling.

❓ estimation

expert

Estimating shard count for expected load

You expect 1 billion user records growing by 10 million per month. Each shard can handle 100 million records efficiently. How many shards do you need initially and after 6 months?

A Initially 5 shards; after 6 months 11 shards

B Initially 10 shards; after 6 months 16 shards

C Initially 15 shards; after 6 months 20 shards

D Initially 8 shards; after 6 months 14 shards

💡 Hint

Divide total records by shard capacity to estimate shard count.

Initially: 1,000,000,000 / 100,000,000 = 10 shards.
After 6 months: 1,000,000,000 + (6 * 10,000,000) = 1,060,000,000 records.
1,060,000,000 / 100,000,000 ≈ 10.6 → 11 shards minimally. Option B (10 initial, 16 after) correctly matches the initial count and provides overprovisioning for safety, ongoing growth, and inefficiencies.