Hashing tenant IDs cannot prevent load skew from one large tenant

A multi-tenant system that hashes tenant_id keeps each tenant's rows together and spreads tenants evenly, but it cannot even out load when one tenant generates most of the writes. In a lab with 100,000 writes across eight shards, one shard received nearly four times the average load while another sat almost idle, so throughput was limited to roughly two machines' worth. Salting the large tenant's key across sixteen variants evens writes but forces every read of that tenant to fan out to multiple shards. Composite keys that add an order sequence also balance load, though queries must then reach all shards, while a dedicated placement for the big tenant isolates it at the cost of needing a larger machine. The author notes that each fix trades write balance against read cost or hardware.