Hvordan ville du shardet en database for 1 milliard brukere?

Question

IT Interview Practice · Accepted Answer

Shard på en nøkkel som er **til stede i nesten hver spørring og sprer belastningen jevnt** — vanligvis en hashet `user_id` — planlegg deretter for resharding og cross-shard-spørringer fra dag én. 1B brukere får ikke plass eller yter ikke på én node; du deler rader over mange databaser og ruter hver spørring til sharden som eier den.

```text
                 ┌──────────────┐
Request ─▶ Router/│ shard_of(key)│─▶ Shard 0  (users 0–…)
           Proxy  └──────────────┘   Shard 1
           (Vitess)      │           Shard 2
                         └─────────▶  Shard N   ← hver = sin egen primary+replicas
Directory/lookup-tabell (hvilken key → hvilken shard) ── for range eller resharding
```

## Valg av shard-nøkkel — beslutningen som er vanskelig å angre

Velg en nøkkel med **høy kardinalitet, jevn distribusjon, og til stede i de fleste spørringer**. `user_id` vinner vanligvis: bruker-scopede spørringer ("min profil, mine ordrer") treffer nøyaktig én shard. En dårlig nøkkel (f.eks. `country`) skaper hotspots — én shard holder hele India mens en annen sitter idle.

## Hash vs range

- **Hash-sharding** (`shard = hash(user_id) % N`): distribuerer jevnt, dreper hotspots — men range-spørringer ("brukere opprettet forrige uke") må scatter-gathere over alle shards.
- **Range-sharding** (`user_id 0–1M → shard 0`): holder ranges lokale og gjør resharding enklere, men risikerer hotspots (nyeste brukere lander alle på siste shard).
- Vanlig svar: **hash for jevn belastning**, med en **lookup/directory-tabell** slik at du kan flytte ranges uten å rehashe alt.

## Resharding — planlegg før du trenger det

`% N` er en felle: å legge til én shard remapper nesten hver nøkkel. Bruk **consistent hashing** eller **virtuelle bøtter** (map keys → 4096 logiske bøtter → fysiske shards). Å splitte en shard flytter da bøtter, ikke hele keyspace-en. Verktøy som **Vitess** (brukt av YouTube/Slack) automatiserer live resharding med cutover.

## Cross-shard-spørringer

Alt som ikke er nøklet på shard-nøkkelen er smertefullt: en global "top posts"-spørring fan-out-er til hver shard og merger. Demp ved å **denormalisere** eller holde en separat indeks/search store (Elasticsearch) for cross-cutting lesninger.

## Intervjuperspektiv

Intervjuere undersøker om du forstår at shard-nøkkel-valg er **semi-permanent** og om du har tenkt på **resharding og cross-shard joins** — de to tingene som biter i produksjon. Bra: "shard på user_id." Utmerket: du bringer opp consistent hashing, hot-shard-demping, og det faktum at distribuerte transaksjoner over shards helst bør unngås helt.

**Vanlig felle:** `hash % N` med en fast N — det gjør fremtidig vekst til en full datamigrering.

## Avveininger og feilmoduser

- **Tapt cross-shard ACID:** ingen billige joins/transaksjoner over shards; bruk sagaer eller denormaliser.
- **Hot shard:** en viral bruker; sub-shard eller cache den entiteten.
- **Rebalanserings-risiko:** live migrering må dobbeltskrive og verifisere før cutover.
- **Operasjonell kostnad:** N shards × replicas = mange databaser å overvåke, ta backup av og fail over.

Valg av shard-nøkkel — beslutningen som er vanskelig å angre

Hash vs range

Resharding — planlegg før du trenger det

Cross-shard-spørringer

Intervjuperspektiv

Avveininger og feilmoduser

Relaterte spørsmål