Hur skulle du sharda en databas för 1 miljard användare?

Question

IT Interview Practice · Accepted Answer

Sharda på en nyckel som är **närvarande i nästan varje fråga och sprider lasten jämnt** — vanligtvis ett hashat `user_id` — och planera sedan för resharding och cross-shard-frågor från dag ett. 1B användare får inte plats eller presterar på en nod; du delar rader över många databaser och dirigerar varje fråga till den shard som äger den.

```text
                 ┌──────────────┐
Request ─▶ Router/│ shard_of(key)│─▶ Shard 0  (users 0–…)
           Proxy  └──────────────┘   Shard 1
           (Vitess)      │           Shard 2
                         └─────────▶  Shard N   ← each = its own primary+replicas
Directory/lookup table (which key → which shard) ── for range or resharding
```

## Val av shard-nyckel — beslutet som är svårt att ångra

Välj en nyckel med **hög kardinalitet, jämn fördelning och närvaro i de flesta frågor**. `user_id` vinner oftast: användarcentrerade frågor ("min profil, mina ordrar") träffar exakt en shard. En dålig nyckel (t.ex. `country`) skapar hotspots — en shard håller hela Indien medan en annan står stilla.

## Hash vs range

- **Hash-sharding** (`shard = hash(user_id) % N`): fördelar jämnt, dödar hotspots — men range-frågor ("användare skapade förra veckan") måste scatter-gathera över alla shards.
- **Range-sharding** (`user_id 0–1M → shard 0`): håller ranges lokala och gör resharding enklare, men riskerar hotspots (nyaste användare landar alla på sista sharden).
- Vanligt svar: **hash för jämn last**, med en **lookup/directory-tabell** så att du kan flytta ranges utan att omhasha allt.

## Resharding — planera innan du behöver det

`% N` är en fälla: att lägga till en shard mappar om nästan varje nyckel. Använd **consistent hashing** eller **virtual buckets** (mappa nycklar → 4096 logiska buckets → fysiska shards). Att splitta en shard flyttar då buckets, inte hela nyckelrymden. Verktyg som **Vitess** (använt av YouTube/Slack) automatiserar live-resharding med cutover.

## Cross-shard-frågor

Allt som inte är nycklat på shard-nyckeln är smärtsamt: en global "top posts"-fråga fan-outar till varje shard och slår ihop. Mildra genom att **denormalisera** eller hålla en separat index/sök-store (Elasticsearch) för tvärgående läsningar.

## Intervjuperspektiv

Intervjuare undersöker om du förstår att valet av shard-nyckel är **semi-permanent** och om du har tänkt på **resharding och cross-shard joins** — de två saker som biter i produktion. Bra: "sharda på user_id." Utmärkt: du tar upp consistent hashing, hot-shard-mildring, och det faktum att distribuerade transaktioner över shards bäst undviks helt.

**Vanlig fälla:** `hash % N` med ett fast N — det gör framtida tillväxt till en full datamigration.

## Avvägningar & felmoder

- **Förlorad cross-shard-ACID:** inga billiga joins/transaktioner över shards; använd sagas eller denormalisera.
- **Het shard:** en viral användare; sub-sharda eller cacha den entiteten.
- **Rebalancing-risk:** live-migration måste dubbelskriva och verifiera före cutover.
- **Driftkostnad:** N shards × replicas = många databaser att övervaka, backa upp och failovera.

Val av shard-nyckel — beslutet som är svårt att ångra

Hash vs range

Resharding — planera innan du behöver det

Cross-shard-frågor

Intervjuperspektiv

Avvägningar & felmoder

Relaterade frågor