Sharding hard
You shard your SaaS database by `OrganizationID` to ensure perfect 'Data Locality' for your clients. What is the most critical risk associated with this decision as your business grows?
- A It will become impossible to perform backups for individual organizations.
- B The 'Whale' Problem: if one client (like a Fortune 500 company) grows so large that their data exceeds the capacity of a single physical server, that company becomes 'un-shardsable'.
- C The database will run out of available unique keys if you have more than 64,000 different organizations.
- D Network latency between microservices will increase because the data is 'pinned' to specific regional datacenters.
Answer: B. The 'Whale' Problem: if one client (like a Fortune 500 company) grows so large that their data exceeds the capacity of a single physical server, that company becomes 'un-shardsable'.
This is the classic trade-off of 'Granularity'. sharding by `OrgID` is extremely efficient for small and medium clients. However, if one client has 50 Terabytes of data, and your largest server only has 20 Terabytes of disk, you cannot store that client anymore. This forces you to implement a secondary sharding layer (like `OrgID + UserID`) which completely breaks the original 'Locality' benefits you designed for. Modern designers often prefer a more granular key (like `UserID`) and use 'Logical Groupings' or specialized indexes to maintain performance.
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)?