Zaprojektuj tablicę wyników (leaderboard) w czasie rzeczywistym dla milionów graczy

Question

IT Interview Practice · Accepted Answer

**Użyj posortowanego zbioru Redis (ZSET) kluczowanego po wyniku: ranking i top-N stają się wbudowanymi operacjami O(log N), więc nigdy nie sortujesz milionów wierszy na żądanie.** ZSET automatycznie utrzymuje członków uporządkowanych po wyniku; to dokładnie jest leaderboard.

## Architektura

```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)
```

## Jak to działa

- **ZADD** wstawia/aktualizuje wynik gracza w O(log N). Redis utrzymuje porządek przez **skip list**, więc żadne ponowne sortowanie nie jest potrzebne.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` zwraca top 100 w O(log N + 100).
- **Twój ranking**: `ZREVRANK board user` daje pozycję liczoną od 0; **around-me** to `ZREVRANGE rank-5 rank+5` — wycinek graczy w twoim pobliżu.
- **Trwałość**: Redis jest in-memory. Włącz **AOF** (append-only file) do odtwarzania i asynchronicznie kopiuj wyniki do **Postgres** jako prawdziwego rejestru systemowego, aby utrata Redis była odzyskiwalna.

## Shardowanie dla milionów użytkowników

Jeden ZSET spokojnie pomieści dziesiątki milionów członków (ograniczony pamięcią, ~100 MB na 1 mln wpisów). Powyżej tego, lub dla skali globalnej, **sharduj po zakresie wyników** (0–1k, 1k–10k…), aby każdy shard był ciągłym pasmem — globalne top-N czyta tylko górny shard. Unikaj shardowania po hashu użytkownika: rekombinacja rankingów z losowych shardów jest kosztowna.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca chce zobaczyć, jak **sięgasz po właściwą strukturę danych**, a nie `ORDER BY score LIMIT 100` na SQL (co sortuje ponownie przy każdym trafieniu i umiera pod obciążeniem zapisami). Dobre odpowiedzi nazywają ZSET; świetne obejmują **zapytania around-me, remisy, trwałość i strategię shardowania**. Klasyczna pułapka: zapominanie, że Redis jest ulotny, i traktowanie go jako źródła prawdy — restart wymazuje tablicę, chyba że istnieje AOF/RDB lub kopia w DB.

## Kompromisy i awarie

- **Remisy.** Równe wyniki są porządkowane leksykograficznie po członku, co wygląda losowo. Zakoduj tiebreaker w wyniku (np. `score * 1e13 - timestamp`), aby wcześniejsi osiągający byli wyżej.
- **Gorący klucz.** Pojedynczy globalny ZSET to jeden klucz na jednym shardzie — hotspot zapisu. Buforuj/grupuj `ZADD`-y lub użyj tablic z bucketami czasowymi (dziennych/tygodniowych), aby rozłożyć obciążenie.
- **Spójność.** Odczyty mogą być opóźnione względem asynchronicznej kopii w DB o sekundy — OK dla leaderboardów, nie dla wypłat; uzgadniaj z Postgres przed przyznaniem nagród.
- **Koszt pamięci.** Miliony członków kosztują realny RAM; wygaszaj sezonowe tablice TTL-ami.
- **Kiedy nie:** leaderboard kilku tysięcy odświeżany co minutę jest OK jako cache'owane zapytanie SQL — ZSET Redis błyszczy, gdy zapisy są stałe, a ranking musi być natychmiastowy.

Architektura

Jak to działa

Shardowanie dla milionów użytkowników

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i awarie

Powiązane pytania