Consistent Hashing medium
Which of these is a BAD choice for a Partition Key for a multi-tenant SaaS app?
- A The `TenantID`, if one tenant is significantly larger than others (the 'Whale' problem), as it creates an un-splittable hot shard.
- B The `UserID`, as it provides a naturally high cardinality that ensures keys are distributed evenly across all cluster members.
- C A composite key like `TenantID + UserID`, which allows for fine-grained sharding even for extremely large enterprise tenants.
- D A standard UUID v4, which offers guaranteed uniform distribution across the entire hash ring address space.
Answer: A. The `TenantID`, if one tenant is significantly larger than others (the 'Whale' problem), as it creates an un-splittable hot shard.
Sharding by `TenantID` is risky in SaaS environments. If an enterprise 'Whale' account has millions of rows while others have hundreds, that entire tenant will hash to one single shard. This hot shard will hit resource limits (CPU/Disk) while other nodes are idle. A better approach is use a more granular key or a composite key to allow a single tenant's data to span multiple nodes.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In a 'Smart Client' architecture (e.g., modern Cassandra drivers), how does the client find the right node?
- When a new node (Node X) joins the ring, where does it acquire its initial data from?
- Google's Maglev hashing algorithm (used in their Network Load Balancers) differs from standard Consistent Hashing rings. How does it generate the lookup table?
- Virtual Nodes improve balance but increase metadata size (Memory). How does 'Multi-Probe Consistent Hashing' achieve good balance without VNodes?
- In the Chord DHT protocol (a P2P consistent hashing implementation), naive lookups are O(N). How does Chord optimize this to O(log N)?
- Which of these systems is a famous user of Consistent Hashing?