The problem
A multi tenant application serves many customers from one system. As the data grows, one database cannot hold it all. Sharding by tenant assigns each customer to a specific shard so the total load spreads across many databases.
How routing works
A small directory maps each tenant id to its shard. Requests look up the tenant, then talk only to that shard.
- A query stays within one shard, which keeps it fast.
- A noisy tenant only stresses its own shard, limiting blast radius.
- Large tenants can be moved to a dedicated shard.
The trade offs
- Cross tenant reporting now spans shards, which is harder.
- Skew is a risk: a few giant tenants can overload a shard while others sit idle.
- You need a plan to rebalance tenants when shards fill up.
Tenant sharding fits naturally when data rarely crosses customer boundaries.
Key idea
Place each tenant on a chosen shard so load spreads and one customer cannot drag down the rest.