Sharding easy
In a social media application sharded by `user_id`, what is the most likely cause of a performance 'Hotspot'?
- A When the physical temperature of one specific database server rises above a safe threshold.
- B When a single high-profile user (a 'Celebrity') attracts millions of interactions, overwhelming the specific shard that stores their data.
- C When the database administrator forgets to apply the latest security patches to one of the nodes.
- D When one shard becomes completely empty while others are at full capacity.
Answer: B. When a single high-profile user (a 'Celebrity') attracts millions of interactions, overwhelming the specific shard that stores their data.
This is known as the 'Celebrity' or 'Whale' problem. If you shard by `user_id`, a typical user might get 5 comments a day, but a celebrity could get 5 million. Because all comments for that user are sharded to the same machine, that server will fail under the load while every other server in the cluster is doing nothing. Solving this requires more advanced strategies, such as further sub-partitioning the celebrity's data or using a different shard key for interactions.
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)?