Design en sanntids leaderboard for millioner av spillere

Question

IT Interview Practice · Accepted Answer

**Bruk et Redis sorted set (ZSET) nøklet på score: rank og top-N blir O(log N) innebygde operasjoner, så du sorterer aldri millioner av rader per request.** Et ZSET holder medlemmer ordnet på score automatisk; det er akkurat hva en leaderboard er.

## Arkitektur

```text
Game svc ──ZADD score──▶ Redis ZSET (sortert på score) ──ZREVRANGE 0 99──▶ Top-100 API
                              │
                              ├─ ZREVRANK user ─▶ "din rank" (around-me: rank±5)
                              └─ AOF/RDB + async ─▶ Postgres (varig sannhetskilde)
```

## Slik fungerer det

- **ZADD** upserter en spillers score i O(log N). Redis vedlikeholder rekkefølge via en **skip list**, så ingen re-sort er nødvendig.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` returnerer top 100 i O(log N + 100).
- **Din rank**: `ZREVRANK board user` gir den 0-baserte posisjonen; **around-me** er `ZREVRANGE rank-5 rank+5` — skiven av spillere nær deg.
- **Varighet**: Redis er in-memory. Aktiver **AOF** (append-only file) for replay, og speil scores asynkront til **Postgres** som det sanne system of record, slik at et Redis-tap er gjenopprettbart.

## Sharding for millioner av brukere

Ett ZSET holder titalls millioner medlemmer fint (minnebundet, ~100MB for 1M oppføringer). Utover det, eller for global skala, **shard på score-range** (0–1k, 1k–10k…) slik at hver shard er et sammenhengende bånd — en global top-N leser kun topp-sharden. Unngå sharding på user hash: å rekombinere ranks over tilfeldige shards er dyrt.

## Intervjuperspektiv

Intervjueren vil se at du **griper til riktig datastruktur** fremfor `ORDER BY score LIMIT 100` på SQL (som re-sorterer ved hvert treff og dør under write-belastning). Gode svar navngir ZSET; utmerkede svar dekker **around-me-spørringer, uavgjort, persistens og shard-strategi**. En klassisk felle: å glemme at Redis er flyktig og behandle den som sannhetskilden — en restart tørker ut boardet med mindre AOF/RDB eller et DB-speil finnes.

## Avveininger og feil

- **Uavgjort.** Like scores ordnes leksikografisk på medlem, som ser tilfeldig ut. Encode en tiebreaker inn i scoren (f.eks. `score * 1e13 - timestamp`) slik at tidligere prestasjoner rangeres høyere.
- **Hot key.** Ett globalt ZSET er én key på én shard — en write-hotspot. Buffre/batch `ZADD`-er, eller bruk tidsbøttede boards (daglig/ukentlig) for å spre belastning.
- **Konsistens.** Lesninger kan henge etter det async DB-speilet med sekunder — greit for leaderboards, ikke for utbetalinger; avstem fra Postgres før tildeling av premier.
- **Minnekostnad.** Millioner av medlemmer koster reell RAM; la sesong-boards utløpe med TTL-er.
- **Når ikke:** en leaderboard på noen få tusen refreshet hvert minutt er fin som en cachet SQL-spørring — Redis ZSET skinner når writes er konstante og rank må være umiddelbar.

Arkitektur

Slik fungerer det

Sharding for millioner av brukere

Intervjuperspektiv

Avveininger og feil

Relaterte spørsmål