# Exercise 1: Choose a Shard Key for a Multi-Tenant SaaS

## Scenario

`FormHive`, a form-builder SaaS, is outgrowing a single database. Every table (`forms`, `submissions`, `form_fields`) belongs to a `tenant_id` (one tenant = one paying company). Query patterns from the access log:

- 97% of all queries — reads and writes both — include `tenant_id` in the `WHERE` clause; the product is fully tenant-isolated, and a user session only ever operates within their own tenant.
- The remaining 3% are internal admin/billing queries that scan across all tenants (e.g. "total submissions across the platform this month").
- Tenant size varies enormously: the largest 50 tenants (out of ~4,000 total) account for roughly 60% of all data and write volume; the other ~3,950 tenants share the remaining 40%.
- `submissions` and `form_fields` are both always queried joined against `forms` (`WHERE forms.tenant_id = ? AND forms.id = submissions.form_id`), never independently.

## Deliverables

1. **Propose a shard key**, justified against theory (Part 1) section 2's rule about matching the highest-volume query predicate, using the 97%/3% split given above.
2. **Choose range or hash sharding** for that key, justified against theory (Part 1) section 3 — explicitly address whether the large-tenant-concentration numbers given (top 50 tenants = 60% of data) change your answer, and if so, how.
3. **Address co-location** — explain, using theory (Part 2) section 3, how you'd shard `forms`, `submissions`, and `form_fields` relative to each other so that the "always joined together" access pattern stays a same-shard join rather than becoming cross-shard.
4. **Address the 3% cross-tenant admin queries** — explain, using theory (Part 1) section 2's scatter-gather concept, what these queries cost under your scheme, and whether that cost is acceptable given they're only 3% of traffic and not latency-sensitive (state your assumption about their latency sensitivity if the scenario doesn't specify it).
5. **Flag the celebrity-shard risk**, if any, created by the top-50-tenants-are-60%-of-data fact, using theory (Part 2) section 4 — is this actually a celebrity-load problem, or just an expected consequence of legitimately large tenants needing proportionally more resources? Justify your answer.