Designa en realtids-leaderboard för miljontals spelare

Question

IT Interview Practice · Accepted Answer

**Använd en Redis sorted set (ZSET) nycklad på poäng: rank och top-N blir inbyggda O(log N)-operationer, så du sorterar aldrig miljontals rader per request.** En ZSET håller medlemmar ordnade efter poäng automatiskt; det är precis vad en leaderboard är.

## Arkitektur

```text
Game svc ──ZADD score──▶ Redis ZSET (sorted by score) ──ZREVRANGE 0 99──▶ Top-100 API
                              │
                              ├─ ZREVRANK user ─▶ "your rank" (around-me: rank±5)
                              └─ AOF/RDB + async ─▶ Postgres (durable source of truth)
```

## Så här fungerar det

- **ZADD** upsertar en spelares poäng i O(log N). Redis upprätthåller ordning via en **skip list**, så ingen omsortering behövs.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` returnerar de 100 främsta i O(log N + 100).
- **Din rank**: `ZREVRANK board user` ger den 0-baserade positionen; **around-me** är `ZREVRANGE rank-5 rank+5` — snittet av spelare nära dig.
- **Hållbarhet**: Redis är in-memory. Aktivera **AOF** (append-only file) för replay, och spegla asynkront poäng till **Postgres** som det sanna system of record, så att en Redis-förlust är återhämtningsbar.

## Sharding för miljontals användare

En ZSET håller tiotals miljoner medlemmar utan problem (minnesbunden, ~100MB för 1M poster). Bortom det, eller för global skala, **sharda på poängintervall** (0–1k, 1k–10k…) så att varje shard är ett sammanhängande band — en global top-N läser bara den översta sharden. Undvik att sharda på användarhash: att återkombinera ranks över slumpmässiga shards är dyrt.

## Intervjuperspektiv

Intervjuaren vill se dig **gripa efter rätt datastruktur** snarare än `ORDER BY score LIMIT 100` på SQL (som omsorterar vid varje träff och dör under skrivlast). Bra svar namnger ZSET; utmärkta svar täcker **around-me-frågor, oavgjorda, persistering och shard-strategi**. En klassisk fälla: att glömma att Redis är flyktigt och behandla det som source of truth — en omstart raderar tavlan om inte AOF/RDB eller en DB-spegling finns.

## Avvägningar & fel

- **Oavgjorda.** Lika poäng ordnas lexikografiskt på medlem, vilket ser slumpmässigt ut. Koda in en tiebreaker i poängen (t.ex. `score * 1e13 - timestamp`) så att tidigare presterande rankar högre.
- **Het nyckel.** En enda global ZSET är en nyckel på en shard — en skriv-hotspot. Buffra/batcha `ZADD`s, eller använd tidsbucketade tavlor (dagliga/veckovisa) för att sprida lasten.
- **Konsistens.** Läsningar kan ligga efter den asynkrona DB-speglingen med sekunder — okej för leaderboards, inte för utbetalningar; stäm av från Postgres innan du delar ut priser.
- **Minneskostnad.** Miljontals medlemmar kostar verkligt RAM; låt säsongstavlor expirera med TTL:er.
- **När inte:** en leaderboard med några tusen som uppdateras varje minut går bra som en cachad SQL-fråga — Redis ZSET briljerar när skrivningar är konstanta och rank måste vara omedelbar.

Arkitektur

Så här fungerar det

Sharding för miljontals användare

Intervjuperspektiv

Avvägningar & fel

Relaterade frågor