Proiectează un leaderboard în timp real pentru milioane de jucători

Question

IT Interview Practice · Accepted Answer

**Folosește un sorted set Redis (ZSET) cheiat după scor: rangul și top-N devin operații built-in O(log N), astfel încât nu sortezi niciodată milioane de rânduri per request.** Un ZSET menține membrii ordonați după scor automat; exact asta este un leaderboard.

## Arhitectură

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

## Cum funcționează

- **ZADD** face upsert la scorul unui jucător în O(log N). Redis menține ordinea printr-un **skip list**, deci nu este nevoie de re-sortare.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` returnează top 100 în O(log N + 100).
- **Rangul tău**: `ZREVRANK board user` dă poziția 0-based; **around-me** este `ZREVRANGE rank-5 rank+5` — felia de jucători din jurul tău.
- **Durabilitate**: Redis este in-memory. Activează **AOF** (append-only file) pentru replay și oglindește asincron scorurile în **Postgres** ca sistem real de înregistrare, astfel încât o pierdere Redis să fie recuperabilă.

## Sharding pentru milioane de utilizatori

Un singur ZSET ține zeci de milioane de membri fără probleme (limitat de memorie, ~100MB pentru 1M de intrări). Peste asta, sau pentru scară globală, **fă sharding după range de scor** (0–1k, 1k–10k…) astfel încât fiecare shard să fie o bandă contiguă — un top-N global citește doar shard-ul de top. Evită sharding-ul după hash de utilizator: recombinarea rangurilor peste shard-uri aleatoare este costisitoare.

## Perspectiva de interviu

Intervievatorul vrea să te vadă **apelând la structura de date potrivită** în loc de `ORDER BY score LIMIT 100` pe SQL (care re-sortează la fiecare hit și moare sub încărcarea de scriere). Răspunsurile bune numesc ZSET; cele excelente acoperă **interogările around-me, egalitățile, persistența și strategia de shard**. O capcană clasică: uitarea că Redis este volatil și tratarea lui ca sursă de adevăr — un restart șterge board-ul dacă nu există AOF/RDB sau o oglindă de DB.

## Compromisuri și eșecuri

- **Egalități.** Scorurile egale se ordonează lexicografic după membru, ceea ce pare aleator. Codifică un tiebreaker în scor (de ex. `score * 1e13 - timestamp`), astfel încât cei care au reușit mai devreme să fie mai sus.
- **Cheie fierbinte.** Un singur ZSET global este o cheie pe un shard — un hotspot de scriere. Fă buffer/batch la `ZADD`-uri, sau folosește board-uri cu bucket-uri de timp (zilnice/săptămânale) pentru a distribui încărcarea.
- **Consistență.** Citirile pot fi în urma oglinzii async de DB cu secunde — în regulă pentru leaderboard-uri, nu pentru plăți; reconciliază din Postgres înainte de a acorda premii.
- **Cost de memorie.** Milioane de membri costă RAM reală; expiră board-urile sezoniere cu TTL-uri.
- **Când nu:** un leaderboard de câteva mii reîmprospătat la fiecare minut este în regulă ca o interogare SQL în cache — ZSET-ul Redis strălucește când scrierile sunt constante și rangul trebuie să fie instantaneu.

Arhitectură

Cum funcționează

Sharding pentru milioane de utilizatori

Perspectiva de interviu

Compromisuri și eșecuri

Întrebări conexe