Hoe zou je een database sharden voor 1 miljard gebruikers?

Question

IT Interview Practice · Accepted Answer

Shard op een sleutel die **in vrijwel elke query voorkomt en de belasting gelijkmatig spreidt** — meestal een gehashte `user_id` — en plan vanaf dag één voor resharding en cross-shard queries. 1 miljard gebruikers passen of presteren niet op één node; je splitst rows over vele databases en routeert elke query naar de shard die hem bezit.

```text
                 ┌──────────────┐
Request ─▶ Router/│ shard_of(key)│─▶ Shard 0  (users 0–…)
           Proxy  └──────────────┘   Shard 1
           (Vitess)      │           Shard 2
                         └─────────▶  Shard N   ← elk = eigen primary+replica's
Directory/lookup-tabel (welke key → welke shard) ── voor range of resharding
```

## Shard key-keuze — de beslissing die moeilijk terug te draaien is

Kies een sleutel met **hoge cardinaliteit, gelijkmatige distributie, en aanwezig in de meeste queries**. `user_id` wint meestal: user-scoped queries ("mijn profiel, mijn orders") raken precies één shard. Een slechte sleutel (bijv. `country`) creëert hotspots — één shard houdt heel India terwijl een andere idle zit.

## Hash versus range

- **Hash sharding** (`shard = hash(user_id) % N`): distribueert gelijkmatig, doodt hotspots — maar range queries ("gebruikers aangemaakt vorige week") moeten scatter-gather over alle shards doen.
- **Range sharding** (`user_id 0–1M → shard 0`): houdt ranges lokaal en maakt resharding eenvoudiger, maar riskeert hotspots (nieuwste gebruikers landen allemaal op de laatste shard).
- Gebruikelijk antwoord: **hash voor gelijkmatige belasting**, met een **lookup/directory-tabel** zodat je ranges kunt verplaatsen zonder alles opnieuw te hashen.

## Resharding — plan vóór je het nodig hebt

`% N` is een valkuil: één shard toevoegen remapt vrijwel elke sleutel. Gebruik **consistent hashing** of **virtual buckets** (map keys → 4096 logische buckets → fysieke shards). Een shard splitsen verplaatst dan buckets, niet de hele keyspace. Tools als **Vitess** (gebruikt door YouTube/Slack) automatiseren live resharding met cutover.

## Cross-shard queries

Alles wat niet op de shard key is gekeyd, is pijnlijk: een globale "top posts"-query waaiert uit naar elke shard en merget. Mitigeer door te **denormaliseren** of een aparte index/search-store (Elasticsearch) bij te houden voor cross-cutting reads.

## Interviewperspectief

Interviewers peilen of je begrijpt dat de shard key-keuze **semi-permanent** is en of je hebt nagedacht over **resharding en cross-shard joins** — de twee dingen die in productie bijten. Goed: "shard op user_id." Uitstekend: je brengt consistent hashing, hot-shard-mitigatie en het feit dat gedistribueerde transacties over shards het best volledig vermeden worden ter sprake.

**Veelvoorkomende valkuil:** `hash % N` met een vaste N — het maakt toekomstige groei een volledige datamigratie.

## Afwegingen & faalmodi

- **Verloren cross-shard ACID:** geen goedkope joins/transacties over shards; gebruik sagas of denormaliseer.
- **Hot shard:** een virale gebruiker; sub-shard of cache die entiteit.
- **Rebalancing-risico:** live migratie moet double-writen en verifiëren vóór cutover.
- **Operationele kosten:** N shards × replica's = veel databases om te monitoren, back-uppen en failoveren.

Shard key-keuze — de beslissing die moeilijk terug te draaien is

Hash versus range

Resharding — plan vóór je het nodig hebt

Cross-shard queries

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen