Ontwerp een real-time leaderboard voor miljoenen spelers

Question

IT Interview Practice · Accepted Answer

**Gebruik een Redis sorted set (ZSET) op sleutel van score: rank en top-N worden ingebouwde O(log N)-operaties, zodat je nooit miljoenen rows per request sorteert.** Een ZSET houdt members automatisch geordend op score; dat is precies wat een leaderboard is.

## Architectuur

```text
Game svc ──ZADD score──▶ Redis ZSET (gesorteerd op score) ──ZREVRANGE 0 99──▶ Top-100 API
                              │
                              ├─ ZREVRANK user ─▶ "jouw rank" (rond-mij: rank±5)
                              └─ AOF/RDB + async ─▶ Postgres (duurzame source of truth)
```

## Hoe het werkt

- **ZADD** upsert de score van een speler in O(log N). Redis houdt de volgorde bij via een **skip list**, dus er is geen hersortering nodig.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` geeft de top 100 terug in O(log N + 100).
- **Jouw rank**: `ZREVRANK board user` geeft de 0-gebaseerde positie; **rond-mij** is `ZREVRANGE rank-5 rank+5` — de slice spelers vlak bij jou.
- **Duurzaamheid**: Redis is in-memory. Zet **AOF** (append-only file) aan voor replay, en spiegel scores asynchroon naar **Postgres** als het echte system of record, zodat een Redis-verlies herstelbaar is.

## Sharding voor miljoenen gebruikers

Eén ZSET houdt tientallen miljoenen members prima (geheugengebonden, ~100MB voor 1M entries). Daarboven, of voor globale schaal, **shard op score-range** (0–1k, 1k–10k…) zodat elke shard een aaneengesloten band is — een globale top-N leest alleen de bovenste shard. Vermijd sharden op user-hash: ranks over willekeurige shards hercombineren is duur.

## Interviewperspectief

De interviewer wil je naar de **juiste datastructuur** zien grijpen in plaats van `ORDER BY score LIMIT 100` op SQL (dat bij elke hit hersorteert en sterft onder write-belasting). Goede antwoorden benoemen ZSET; uitstekende antwoorden dekken **rond-mij-queries, ties, persistentie en shard-strategie**. Een klassieke valkuil: vergeten dat Redis vluchtig is en het als source of truth behandelen — een herstart wist het bord tenzij AOF/RDB of een DB-spiegel bestaat.

## Afwegingen & faalmodi

- **Ties.** Gelijke scores ordenen lexicografisch op member, wat willekeurig oogt. Codeer een tiebreaker in de score (bijv. `score * 1e13 - timestamp`) zodat wie eerder presteerde hoger rankt.
- **Hot key.** Eén globale ZSET is één key op één shard — een write-hotspot. Buffer/batch `ZADD`s, of gebruik time-bucketed borden (dagelijks/wekelijks) om belasting te spreiden.
- **Consistentie.** Reads kunnen seconden achterlopen op de async DB-spiegel — prima voor leaderboards, niet voor uitbetalingen; reconcileer vanuit Postgres vóór het toekennen van prijzen.
- **Geheugenkosten.** Miljoenen members kosten echt RAM; laat seizoensgebonden borden verlopen met TTLs.
- **Wanneer niet:** een leaderboard van een paar duizend, elke minuut ververst, is prima als een gecachte SQL-query — Redis ZSET schittert wanneer writes constant zijn en rank direct moet zijn.

Architectuur

Hoe het werkt

Sharding voor miljoenen gebruikers

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen