System Design & Architecture Interview Question 5: Hot Tenant Shard Key
System Design & Architecture Interview Questions · Test 1 · question 5 of 10
A multi-tenant analytics service stores events in a database sharded by hash(tenant_id) across 16 shards. One very large tenant now produces about 40% of all writes. Its shard is saturated while the other 15 are mostly idle. The team added 8 more shards, but the problem did not change. That tenant's write volume is expected to keep growing beyond what any single database node can handle.
What is the most effective fix?
Show answer and explanation
Answer:
This is a hot key. However the hashing works, every row with the same tenant_id maps to the same shard, so one tenant's load can never exceed one node's capacity. The fix is to give the hot tenant's data a higher-cardinality key: a composite key such as (tenant_id, hash(event_id) mod N). That splits the tenant into N sub-partitions that land on different shards. The cost is that reads for that tenant must fan out across the N buckets and merge the results. That is usually acceptable for the few tenants that need it.
Option A only changes how many keys move when shards are added. Consistent hashing still sends one tenant_id to one shard, which is why adding 8 shards already failed.
Option C does not help. Range sharding still keeps each tenant's rows together on one shard, and it tends to create more hotspots, not fewer.
Option D is vertical scaling. It raises the ceiling once, but the stem says the tenant's volume will outgrow any single node. It also pays for bigger machines on 15 shards that are idle.
Reference: Sharding pattern - Azure Architecture Center