7. Sharding
7.2 Sharding for Multitenancy
SaaS products are often multitenant — each tenant is a customer. Multiple users may log in to the same tenant, but each tenant has a self-contained dataset separate from other tenants. (An email marketing service: each business is a tenant; its newsletter sign-ups and delivery data are separate from other businesses'.)
Either each tenant gets a separate shard, or multiple small tenants are grouped into a larger shard. Shards might be physically separate databases (cf. the embedded-storage-engine-per-tenant idea in Ch 4) or separately manageable portions of a larger logical database.
Seven advantages:
| Advantage | Why it matters |
|---|---|
| Resource isolation | One tenant's expensive operation is less likely to affect other tenants on different shards |
| Permission isolation | If there's a bug in your access control logic, you're less likely to accidentally give one tenant access to another's data when the datasets are physically separate |
| Cell-based architecture | Apply sharding not only at storage but to the SERVICES running your application code. Services + storage for a set of tenants form a self-contained cell; cells run largely independently. A fault in one cell remains limited to that cell — fault isolation |
| Per-tenant backup and restore | Restore one tenant's state without affecting others — useful when a tenant accidentally deletes or overwrites important data |
| Regulatory compliance | GDPR/CCPA rights to access and deletion become simple export and deletion operations on that person's shard |
| Data residence | A region-aware database can assign a tenant's shard to a particular region to satisfy data residency laws |
| Gradual schema rollout | Roll out migrations one tenant at a time — reduces risk by detecting problems before they affect all tenants, but can be difficult to do transactionally |
Three challenges:
- It assumes each individual tenant fits on a single node. If you have one tenant too big for a machine, you need sharding WITHIN that tenant — back to sharding for scalability
- Many small tenants → a shard each may incur too much overhead. Group them — but then you have the problem of MOVING TENANTS between shards as they grow
- Cross-tenant features become harder if they need joins across shards